Re: AuthorizationExecuteWithPrivileges(): implementation bug or correct behavior?
Re: AuthorizationExecuteWithPrivileges(): implementation bug or correct behavior?
- Subject: Re: AuthorizationExecuteWithPrivileges(): implementation bug or correct behavior?
- From: OL&L Lists <email@hidden>
- Date: Thu, 10 Mar 2005 00:29:56 -0800
At 10:00 AM -0500 2/14/05, Darkshadow wrote:
What is happening (with me at least), is that
AuthorizationExecuteWithPrivileges() *is not* displaying a dialog to
gain the system.privilege.admin right. It's being granted without
displaying the dialog.
That means the SS has looked in its credentials cache and is
satisfied that the requested right/authorization has already been
granted. Again, there are no Apple-published rules on how/when the SS
caches privileges so it's SS weirdness. I have even seen machines sit
for 24 hours with certain authorizations and re-executing the same
code does not cause SS to re-prompt. In other cases I have seen SS
prompt when it *appears* that it shouldn't. The decision to prompt or
not is determined entirely by the internals of the SS. If it thinks
some authorization is being requested that hasn't been granted, it
will prompt. If it is satisfied that the request has already been
authorized/granted, then no prompt. Weird, but that is the way it
makes decisions.
The helper tool successfully relaunches itself via AEWP() and
repairs itself. After the run, the helper tool is setuid root.
This happens on both of my machines. In any user account. Did you
try my code (and edit it to have your admin name/password)?
And yes, you're right, the name and password aren't being passed,
the security token for that granted right is passed. Bad choice of
words on my part. Which is why I said I *should* have expected it,
since the username/password is part of that particular token.
The typical scenario is to have the caller (usually an app) hold a
global AuthorizationRef and then once authorized, pass it back
repeatedly to the helper in order to prevent the SS from
re-prompting. Note I say *usually*.
I never expected AEWP() to not display a dialog, even after I
realized that the username/password was present in the authorization
ref it is using. Which is why I posted this.
As I mentioned, this is entirely expected. If the SS deems the
authorization for the right requested has already been granted (by
finding it in its cache), then it will go ahead and allow the
privileged op because the right has already been granted. It only
presents the dialog when it receives a request for something that it
doesn't think it has granted a right for previously (or has
timed-out) - then the user will get the dialog. Because you had
called AEWP before and the right was granted (and is now cached), you
won't get the dialog the 2nd time.
However, try this test: authorize the first time, leave the program
running, let the machine sit for 2 hours, then come back and execute
AEWP again. My prediction is now you will see the prompt again -
because the SS has revoked the right since the machine has been
sitting idle so long - it doesn't want to leave an unused machine
sitting wide open for long periods of time - bad security idea.
Michael
Orbital Launch & Lift, Inc.
http://www.orbitallaunch.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden