I don't understand how the app allowed to use that file descriptor to read the file's contents.
Its a general UNIX thing. If you have a book on UNIX interprocess communications, you can probably find some details in it. And as others have pointed out, permissions are checked at the time of the initial open only.
but how can another process just start using that descriptor? Is it because it's the parent process?
I am pretty sure your helper tool's parent process is actually the launchd process which is owned by root.
The app only preauthorized some arbitrary right, it didn't actually get any privileges to open and read a protected file.
Authorization in MacOS X is a little difficult for me to get my head around, but here is what I think is happening. When you authorize or preauthorize, you can have those authorization rights credentials stick around for a specified period of time. This authorization credential cache is global, so other processes can look into it. Then later when another process (i.e., your HelperTool) needs authorization to do something, like opening the file, it first checks the cache to see if you already have the credential. If so, it doesn't bother to prompt you again to access your password.
One reason to preauthorize in your Cocoa app is simply to prevent your code from launching the helper tool if you aren't going to be able to provide the right information (i.e., password) in the first place.
Todd _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
