Re: NSTask as root
Re: NSTask as root
- Subject: Re: NSTask as root
- From: Hamish Allan <email@hidden>
- Date: Fri, 18 Mar 2005 20:35:45 +0000
On Fri, 18 Mar 2005 09:54:32 +0100, Stephan Ruggiero
<email@hidden> wrote:
Hi,
I've been messing around with this problem for wuite a while now and I
found the BLAuthentication class the most convenient way to do it. Do a
Google search and you will find places to download the class. You just
have to call the "executeCommand" method to have the user authorize and
then "sudo" the task.
I also read that some think BLAuthentication is a "dirty" way to
implement root tasks, but I did not figure out any other convenient
way...
The whole way authentication on OS X is handled makes me feel uneasy,
and I really think that Apple need to do some work on it. I'd like to
see standard Cocoa classes which handle much more of the complexity of
their security model, because otherwise we're going to see a whole lot
of roll-your-own solutions that may or may not be well-conceived. I'd
like to see something like NSAuthorizedTask which would handle the
whole business of setuiding the target executable if necessary
(although as far as I can tell the setuid tool approach is designed for
situations in which an administrator wants an authorization right to
persist between invocations of a program, which is probably not always
the case). And it should do so without the user ever needing to enter
their admin password twice (as can be the case if the tool needs to be
setuid), which brings me to my next concern about authorization on OS
X...
Users need to be educated to be more wary about having to type in their
admin password. Some of this might be alleviated in other ways e.g., by
having the installer ask you what type of install you want (perhaps
defaulting to using ~/Library and ~/Applications), but I think more
importantly the authorization dialog needs to be special in some way
that cannot be simulated by a user-space program (like the way login in
Windows NT requires the user to press ctrl+alt+del which is the only
key combination that cannot be overridden by userspace software) --
something like turning the Apple logo in the menubar red would be
ideal. Otherwise, what's to stop somebody writing a background app
which waits for an auth window to pop up, clones its contents, and
displays the clone immediately after that window has disappeared? Most
users would just think they had typed their admin password wrongly and
type it in again. Security is only as strong as its weakest point --
often the user.
Best wishes,
Hamish
P.S. While we're nearabouts the subject, is anybody else getting
pestered by Keychain a lot more these days? I don't know whether it was
altered by some system update or other but my login keychain keeps
asking to be unlocked (I have it tied to my login password, so it never
used to). I ran Apple's Keychain First Aid utility and it told me that
something was broken, I repaired it and it verified okay, but I still
get pestered for my login keychain password all the time. Perhaps
somebody wrote that trojan I was describing above ;)
_______________________________________________
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