Programmatically elevate privileges for writes

[beltex]

Writing to the SMC requires root (setFanRPM() for example). Currently, this is done by simply running the process as root (sudo). Instead we want to do this programmatically, prompting the user for privileges (credentials).

See "Elevating Privileges Safely" Apple doc.

[beltex]

Update

AuthorizationExecuteWithPrivileges() was deprecated in 10.7 and doesn't look to be available any longer in 10.9+ (at least for Swift, seems to be available to Objective-C code though - see smcFanControl. Have to look into this further), which Swift requires. So using Authorization Services doesn't look like an option anymore. In addition:

"The reason why AEWP was deprecated is because it's whole security model is hopelessly broken. That makes providing a drop-in replacement somewhat pointless, in that it would just add back in the broken security." -via Apple dev forums

The new recommended approach it seems is to write a privileged helper thats invoked via launchd. See Apple's sample project, SMJobBless. However, this will require a cert from Apple for code signing that will carry a yearly fee (have to look into this further). Thus, if there is a way to integrate a helper that can be optionally used (turned easily off for those that don't have there own cert), this approach can be taken. Or, possibly just distribute the framework as a binary (signed already of course). But this is currently problematic with Swift and will cause issues for those trying to contribute to the project (faced with the same cert issue again). Otherwise, privileges are simply left up to the client, which is not entirely unreasonable (this currently only affects setFanRPM()).

For more see:

• "Deprecated Authorization Services Functions" Apple doc
• http://stackoverflow.com/questions/6841937/authorizationexecutewithprivileges-is-deprecated
• http://stackoverflow.com/questions/25020783/how-to-distribute-swift-library-without-exposing-the-source-code

[beltex]

TODO: See SFAuthorization, may be of use

[beltex]

Closing this for now. Consensus at this time is to simply leave this to the client, which as mentioned before is not unreasonable. Keeps SMCKit code clean, and in any non-trivial situation, client would want to handle auth anyway since its sensitive. For all other cases, trivial ones that is, sudo does the job.

[beltex]

As a followup on this, with 10.11's new System Integrity Protection feature, things are getting lockdown further, reinforces the point that its up to the client to handle privileges. I'm not even sure that privileged helpers will work either anymore. Tracking this in beltex/dshb#27