Re: Using the security framework
Re: Using the security framework
- Subject: Re: Using the security framework
- From: Joe Turner <email@hidden>
- Date: Thu, 22 Jan 2009 16:09:36 -0600
Thanks again for the speedy responses!
On Jan 20, 2009, at 1:47 AM, Nick Zitzmann wrote:
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).
I see. Then, how would you suggest to create a cloner/deleter, if it
needs root privileges, but cannot use the security framework?
What I did a bit ago was, from the command line (NSTask) call a sudu
and then run ditto or rsync, and used a pipe to give it the password.
I had a custom password view where the user entered their password.
The only thing is, I am trying to make external shell scripts
unneeded, which is why I originally just wanted to use NSFileManager.
And, since running scripts from root is dangerous, then is there any
good way to be able to delete protected (not your user account) files?
Or, should I just have it copy or delete files the user has access to?
Or is there a way other than the security framework to delete files
the user does not have access to.
Thank you again for all your help!
Cheers,
Joe Turner
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 (email@hidden)
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:
This email sent to email@hidden