AuthorizationExecuteWithPrivileges(): implementation bug or correct behavior?
AuthorizationExecuteWithPrivileges(): implementation bug or correct behavior?
- Subject: AuthorizationExecuteWithPrivileges(): implementation bug or correct behavior?
- From: Darkshadow <email@hidden>
- Date: Mon, 14 Feb 2005 05:00:12 -0500
Hey all, I have a question for consensus on. I was playing around with
authorization stuff, and decided to try out the environment settings.
The docs say that this isn't used... but it is. (Should probably file
a documentation bug against that; I'll try to remember)
So what I have, is a Foundation tool that calls the authorization
stuff, with an admin user's name and password passed in as the
environment. I was just testing to see if it would display a dialog
asking for authorization given this. It didn't, which I was expecting.
I also have it calling a helper tool (in the test all it does is list
the directory contents of /var/root). It calls
AuthorizationExecuteWithPrivileges() to self repair, as is usual for
helper tools. 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.
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... )
You can download my test files at
<http://homepage.mac.com/darkshadow02/authtest.tar.gz>. If you want to
test this out, you'll need to edit main.m, and add in your admin name
(user name or real name; doesn't matter) and password. Yes, I know,
bad to put it in the code, but it's test code after all. I'd say
delete it afterwards if you're paranoid about it. ;) It'll be lines 88
and 89 where you do this, and you'll also need to plug in their length
at lines 97 and 101. Note that if you don't edit the file, it'll work
as if there were no username/password passed in - in other words, how
it normally would.
This isn't an Xcode project, just the two files that create the
Foundation tool and helper tool. So, for ease with copy & paste:
gcc -O3 -Wall -framework Foundation -framework Security main.m -o
testTool
gcc -O3 -Wall -framework CoreFoundation -framework Security helper.c -o
helperTool
To get the full effect, run this from a non-admin account, or go into
System Preferences and lock one of the panes. The test authorizes
against the system.preferences rights.
This works in 10.2.8 as well - it may work on earlier systems/versions,
but I don't have an install earlier than 10.2.8 to test that with.
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