I just learned that my Mac program Find Any File crashes when using its “root mode” search (by holding down the Option key when clicking “Find”) on Mavericks.
Turns out that the code I’m using to re-launch FAF with root permissions has a bug in which it passes the wrong value to the function AuthorizationFree().
If you’re also using the AuthorizationShell (originally written by Jonathan Johnson, it appears), look for this line:
declare sub AuthorizationFree lib "Security" ( byref ref as integer, flags as Integer)
The “byref” needs to be removed, i.e. the correct line is:
declare sub AuthorizationFree lib "Security" (ref as integer, flags as Integer)
I seem to have lost the source code for Jonathan’s AuthorizationShell, and it doesn’t appear to be available online anymore. Do you know if it’s still available for download somewhere?
Okay, so I just spent the last 2 hours cleaning up my own version, adding documentation and improving the example.
My version also fixes the aforementioned crash and allows you to specify user name and password in code:
Okay, so I just spent the last 2 hours cleaning up my own version, adding documentation and improving the example.[/quote]
Wow, thank you very much for making this available!
That is a great idea!
Yes, correct. However, I understand that Apple has made the new and improved way of doing this exceedingly difficult and painful to use. I believe that AuthorizationShell will continue to work for some good amount of time before a future release of OS X doesn’t support it anymore. I can live with that for now.
They do have a habit of doing that! But be warned, if you can spend the time now and figure it out. Otherwise it can be 10.9.1 it gets removed. I’m not kidding either! It could also 10.12 before it’s removed, you simply don’t know. If you’re having difficulty, post the code to the forum and we’ll help you out.
It is quite a hassle. I suggest we try to tackle it as a community. I spoke with Thomas earlier, and as I told him, I’ve only done a little research on it, but from what I can tell it will be quite a task to do it the “right” way.
The new way has some distinct advantages though, such as only requiring the password once, even between relaunches.
There is little reason for Apple to remove this deprecated API call. I would break many Installers, for instance. Also, it’s not unsafe, but just not the most effective way any more. More than once Apple explained that deprecation first and foremost means: If you start a new project, please do not use deprecated APIs but use the newer (improved) ones instead.
It’s not the same way Xojo usually handles deprecation (i.e. removal without replacement).
It seems Apple would beg to differ - and you should take it up with them
Discussion
This function enables you to execute the tool you specify in the pathToTool parameter as a separate, privileged process. The new process will run with root privileges regardless of the privileges of the invoking process. The new process can retrieve the authorization reference by calling the function AuthorizationCopyPrivilegedReference. The arguments you pass in the arguments parameter are relayed to the new processs argv parameter. A set of file descriptors is linked to the new processs standard input and output so that your process may communicate with the new process.
To check if the user is authorized to perform this operation, you should preauthorize the kAuthorizationRightExecute right. See AuthorizationItem for a description of what information is included in the authorization item for this right.
Special Considerations
You should use this function only to allow installers to run as root and to allow a setuid tool to repair its setuid bit if lost. This function works only if the Security Server establishes proper authorization.
This function poses a security concern because it will indiscriminately run any tool or application, severely increasing the security risk. You should avoid the use of this function if possible. One alternative is to split your code into two partsthe application and a setuid tool. The application invokes the setuid tool using standard methods. The setuid tool can then perform the privileged operations. If the tool loses its setuid bit, use the AuthorizationExecuteWithPrivileges function to repair it. Factoring your program minimizes the use of this function and reduces the risk of harm. Read Inside OS X: Performing Privileged Operations With Authorization Services.
Note that this function respects the setuid bit, if it is set. That is, if the tool you are executing has its setuid bit set and its owner set to foo, the tool will be executed with the user foos privileges, not root privileges. To ensure that your call to the AuthorizationExecuteWithPrivileges function works as intended, make sure the setuid bit of the tool you wish to execute is cleared before calling AuthorizationExecuteWithPrivileges to execute the tool.
Availability
Available in OS X v10.0 and later.
Deprecated in OS X v10.7.
