On Jan 19, 2009, at 7:56 PM, Joe Turner wrote:
That makes sense, but then how does an app like SuperDuper! do it. You click the lock, enter your password, and then you don't need to enter your password again until you lock it again. And, it is the regular security framework password window, so the developer must be doing some sort of authorization that lasts forever. And I checked, it does authorize system.privilege.admin.
There is no authorization that lasts forever. Either it's polling to keep the authorization alive (which may theoretically work, though I've never tried it), or it forgot to set the authorization view to auto-refresh the authorization status (which I think has to be done in code).
Makes sense. So, if I create a separate target for the unix script,
I wouldn't really recommend running shell code with root privileges as a user other than root. That can be a security hole waiting to happen, since changes to the user's environment will affect the script. AEWP() executes things with root privileges, but not _as_ root (so it'll be executed as the user). There are workarounds to this, but the best workaround is to just avoid this if at all possible.
do I need to add something to it that takes the authorization? Or will anything it does that uses admin files be allowed?
Once you run something with AEWP(), it has root privileges. Nick Zitzmann <http://www.chronosnet.com/> _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
