• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Simple authorization question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Simple authorization question


  • Subject: Re: Simple authorization question
  • From: James Bucanek <email@hidden>
  • Date: Thu, 5 Jul 2007 09:22:01 -0700

Alastair Houghton <mailto:email@hidden> wrote (Wednesday, July 4, 2007 10:57 AM +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 think the original poster is targeting those users who aren't running in an admin account, but still have the username and password of an administrator. Which is perfectly ligitimate.


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.

You're right. My bad. That's what I get for posting a solution from memory of a two-year-old project. *sigh*


I want back and looked at my solution, and what it *actually* does it use AuthorizationCreate to obtain a kAuthorizationRightExecute. It then launches a helper application which uses AuthorizationExecuteWithPriveleges to run itself as root. It does its thing and exits.

The whole seteuid()/setuid() mess was actually to solve another problem. The two are related, because you can't call seteuid()or setuid() unless your process is running in a privileged state, which is what AuthorizationExecuteWithPriveleges gets you. But getting the authorization is not what grants the process those rights.

So apologies for leading you down the garden path. I will make a couple of other suggestions:

- The Sparkle suggestion is good. I use it. You'll have to see how it deals with non-admin users.

- Try AppleScript instead. Launch a script that tells the Finder to copy the application to the /Applications folder rather than trying to do it yourself. If the user doesn't have privileges to that folder, the Finder should prompt for an admin username & password.

--
James Bucanek

_______________________________________________

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


References: 
 >Re: Simple authorization question (From: Alastair Houghton <email@hidden>)

  • Prev by Date: Drag button within bounds of superview.
  • Next by Date: Re: Memory Management Question
  • Previous by thread: Re: Simple authorization question
  • Next by thread: Re: Simple authorization question
  • Index(es):
    • Date
    • Thread