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: Mon, 14 Feb 2005 10:00:29 -0500
On Feb 14, 2005, at 7:14 AM, Finlay Dobbie wrote:
On Mon, 14 Feb 2005 05:00:12 -0500, Darkshadow <email@hidden>
wrote:
So here, what I *didn't* expect, was that having passed
the external form of the authorization ref from the Foundation tool to
the helper tool, the name and password are sent along with it (yes, I
probably should have expected this... ) - and
AuthorizationExecuteWithPrivileges() *does not* display an
authorization dialog.
It's not passing the name and password. It never passes the name and
password. It passes a reference to some authorization tokens.
AuthorizationExecuteWithPrivilges is displaying a dialog because it's
trying to gain the right system.privilege.admin - at least it
certainly does here. You don't get a dialog for system.preferences
because you've already authenticated with the username and password
hardcoded into the source.
So to clarify:
1. User runs the authtest (main.m) tool.
2. User gains the system.preferences right (either because they're
already admin, because you put the name/password in the source, or
because they typed it into the authentication dialog).
3. Auth ref passed to helper.
4. If helper is not setuid root, it attempts to gain the
system.privilege.admin - which will prompt a dialog in all cases
except for if the original tool was invoked as root.
5. Once the tool has been repaired, it does not need to gain the
system.privilege.admin right again (since that's only needed for
AEWP() to gain euid=0, and it already has euid=0 due to being suid),
so you don't get the authorization prompt dialog.
Does that make sense?
I understand how the authorization stuff works. No problems there.
Not even asking that. :P
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. 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.
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.
My question, then, is does anyone think this is an implementation bug
in AuthorizationExecuteWithPrivileges(), or is this the behavior to be
expected? A user would never get an additional authorization dialog
and would never know that something had been executed as root with
this
in place - which seems to me a bad thing. (OK, it's debatable on
whether or not the average user would know something was executed as
root anyways... but still... )
If once the executable is in place and setuid root, the user doesn't
need to authenticate in order to run it. This is why it's very
important to implement your own restriction in your tool to ensure it
doesn't get abused.
-- Finlay
And again, I do already know that. Not even an issue I brought up... I
know you answer pretty much every basic authorization question that
pops up - was this just an automatic reply type of thing?
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