Re: AuthorizationExecuteWithPrivileges(): implementation bug or correct behavior?
Re: AuthorizationExecuteWithPrivileges(): implementation bug or correct behavior?
- Subject: Re: AuthorizationExecuteWithPrivileges(): implementation bug or correct behavior?
- From: Finlay Dobbie <email@hidden>
- Date: Mon, 14 Feb 2005 12:14:26 +0000
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?
> 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
_______________________________________________
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