Re: AuthorizationExecuteWithPrivileges(): implementation bug or correct behavior?
Re: AuthorizationExecuteWithPrivileges(): implementation bug or correct behavior?
- Subject: Re: AuthorizationExecuteWithPrivileges(): implementation bug or correct behavior?
- From: Darkshadow <email@hidden>
- Date: Thu, 10 Mar 2005 09:23:52 -0500
Heh, talk about dredging up an old thread. ;)
On Mar 10, 2005, at 3:29 AM, OL&L Lists wrote:
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.
I would agree with you on that, but it's *not* the same right that is
being requested. I authorized against system.preferences. Which, for
the admin account, was already authorized (as per normal), and for the
test user I created, I wasn't asked, since I had put in the admin
name/password in the environment of the authorization ref. That was
expected. Then, the helper tool gets the external form of this
authorization ref passed to it, and used it to call AEWP() which goes
against the system.privilege.admin right. While I can see this
passing, as I did indeed pass it an authorization ref that "contained"
the admin's name/password, I still don't think that should be normal.
It's a totally different right. And just to note, I wasn't using
pre-authorization either.
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*.
Again, I *do* know how to do authorization. I was playing with the
environment settings, seeing what worked and what didn't, and this
surprised me. This wasn't made for production code in any way. Just
playing around with the security settings. Whimsical me and all. ;)
[from the other email]
What I *would* say you shouldn't do is be passing in the authorization
in the environment. That could be a security risk since a malicious
app could attach to the caller and gain root access that way. Apple
recommends to always destroy the inherited environment once inside the
helper tool.
[end other email]
I'm not passing it via the environment, I used an
AuthorizationEnvironment set which contained the user name and password
as items, and passed that into the environment section of
AuthorizationCreate(). The authorization ref is passed to the helper
tool in external form via stdin. I checked the environment that is
passed to the helper tool - neither the name or password is actually
present. They're part of the authorization ref's environment, for lack
of a better description.
I did note that the helper tool, when re-run as root after AWEP() has
successfully been called, has one additional environment variable named
__AUTHORIZATION. If you explicitly remove this from the environment,
calling AuthorizationCopyPrivilegedReference() will fail when trying to
retrieve the authorization ref. I'm guessing this is a normal
addition, as completely taking out the environment sets I created still
results in the creation of this environment variable, and it's *only*
ever available after the AEWP() function has been called to relaunch
the helper tool as root.
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.
And I did try that test. Many times. I left my machine logged into
the console for an entire weekend, came back and ran it, and it worked
(I'm curious as to what would have happened had it needed to ask for
the password. I know, I could test that, but I never got around to
it).
Either my system is possessed, or this is just granted (on my machine).
My iBook does ask for the password before AEWP() will run (previously I
said it passed on that as well - after a restart, it acted "normally"
asking me for my password first), but my desktop won't. I even did a
clean install of 10.2 and 10.3 and tested it out. It just works on my
machine. I, personally, think it's strange behavior, since I expect
AEWP() to ask for the password if it hasn't been previously called and
granted or has timed out from a previous call. Though you do bring up
an interesting thing there, I wonder if AEWP() would possibly not time
out after 5 minutes in some situation. That would be a pretty big bug.
I hope that one doesn't happen.
Michael
Orbital Launch & Lift, Inc.
http://www.orbitallaunch.com
I also still haven't resolved why this works on my desktop machine but
not on my iBook (or why it worked on the iBook until a restart,
either). They are almost perfect copies of each other. Any small
changes I've done to configuration stuff on one I've done to the other.
They both have the same applications running. I can restart the
desktop as many times as I want, boot into 10.2 or 10.3, leave it on
for hours at a time, come back and run that test code and it works.
Never asks me for a password. I gave up on it. It wasn't like I was
wanting to do it in actual code. Just a curiosity on my part of how
different environment settings would effect the authorization ref.
This particular setting seemed off to me, so I sent the mail to the
list asking about it.
I'm thinking my desktop has just been around long enough that it knows
I hate being asked for passwords. ;)
Darkshadow (aka Michael Nickerson)
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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