Re: Simple authorization question
Re: Simple authorization question
- Subject: Re: Simple authorization question
- From: Alastair Houghton <email@hidden>
- Date: Wed, 4 Jul 2007 18:57:36 +0100
On 4 Jul 2007, at 18:28, James Bucanek wrote:
Martin Hairer <mailto:email@hidden> wrote (Wednesday, July
4, 2007 5:54 AM +0100):
Hi, I have a simple helper app that allows my main application to
self-update. The helper app simply copies the updated application
into the "Applications" folder. All works fine, as long as the
user has admin privileges...
Which is probably how it *should* work. Users without admin
privileges probably shouldn't be updating software in /Applications
anyway.
I tried to get the helper application to gain admin privileges by
adding the line
[[SFAuthorization authorization]
permitWithRight:kAuthorizationRightExecute
flags:(kAuthorizationFlagInteractionAllowed |
kAuthorizationFlagExtendRights)];
The authorization call you made should grants your process
administrative privileges. But being granted that right does not
invoke that right. After the permitWithRight message returns
successfully, it means that your process now has rights that it
didn't have before. In other words, it doesn't change anything, it
just removes barriers. Your process can now blithely perform
operations that it was heretofore prohibited from doing (that's
what the documentation paragraph is trying to explain -- once you
have the rights to do something, you simply do it).
No, it doesn't work like that.
The way things actually work is as follows:
1. The security server maintains the set of rights currently allotted
to your process.
2. When you use the Security framework to ask for a right, it will
request the relevant right from the security server. The security
server will use the rules in the Authorization database (/etc/
authorization, currently) to decide whether to issue the right, and
whether any access checks or passwords need to be requested first.
3. The fact that you now have a particular right *only influences
things that check for that right*. In particular, **IT DOES NOT HAVE
ANY IMPACT ON THE BSD SECURITY MODEL**. That's a very important
thing to remember, which is why I put it in uppercase and with "**"s
around it.
So this:
One of these rights is the ability to change the effective user ID
of your process. Now that your process has administrative
privileges, it can temporarily become the root user:
seteuid(0);
is emphatically *not* true.
What you must do instead is factor your application into the Cocoa
front-end and a "helper tool" back end. See
<http://developer.apple.com/documentation/Security/Conceptual/
authorization_concepts/index.html>
(in particular the section "Authorizing in a Factored Application")
for more information.
Also, it is best to authorize for a more descriptive right if
possible (rather than kAuthorizationRightExecute). For instance, you
might choose "com.hairersoft.MartinsApp.update" as your right. Also,
you can put descriptive information in the environment: argument of
the -permitWithRights:flags:environment:authorizedRights: message,
which is a very good idea because a right string may not mean much to
a normal user.
Kind regards,
Alastair.
--
http://alastairs-place.net
_______________________________________________
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