Re: Authorization without permanent setuid on helper
Re: Authorization without permanent setuid on helper
- Subject: Re: Authorization without permanent setuid on helper
- From: OL&L Lists <email@hidden>
- Date: Fri, 21 Jan 2005 23:26:17 -0800
At 8:48 PM -0800 1/21/05, John Davidorff Pell wrote:
On 21 Jan 2005, at 17:11, Finlay Dobbie wrote:
On Fri, 21 Jan 2005 16:41:24 -0800, John Davidorff Pell
<email@hidden> wrote:
I very much do not like this. Personally, I would prefer to be prompted
every time that a root operation is performed. I go out of my way to
remove setuid binaries from my system. I think they are inappropriate.
If a user should be allowed to perform an operation, then they should
have permission to do so. They should not circumvent the permissions
model by using a setuid binary.
You'd like to be prompted to authenticate to get a process list? To
change your network preferences? To change your date/time? Wow, you
must like pain, and I have to say I'm in favour of getting stuff done
rather than pointless bureaucracy :-)
There is no need to be root to get a process list and there is no
reason to change the date or time often. I would rather be asked
(more like notified) if someone is trying to change my system clock,
to use your example. The one time that I set the clock after
install, putting in my password is absolutely acceptable.
No, but there may be a need to do other privileged operations often:
like changing the network settings. That *does* require being root.
The fundamental problem here is that the UNIX security model is
outdated and inflexible. Some things require root privs when they're
relatively innocuous.
You seem to have a very static idea of the "UNIX security model".
All flavours of unix that I have ever used require different privs
for dozens of operations, including but not limited to, opening a
tty, getting a process list, or accessing various devices (such as
the frame-buffer). If a particular operation, say getting a process
list, requires root privs on UNIX flavour O, that just means that
UNIX flavour N, which does not require such privs, has one extra
selling point.
It's for developers to make informed and
educated decisions as to how to expose this stuff to the user, which
is sometimes not easy. While I certainly don't trust every random
developer on the platform, I don't see any viable alternative.
I would be happy so long as all possible effort is made to avoid
running something as root. If it is required to use some feature of
your program, and I as a user want that feature, then obviously I'll
live with a process running as root.
The point is, sometimes it's unavoidable - like in the case of
setting network preferences. In that case you have to run as root.
And prompting the user once for admin password and then caching that
password and reusing it is perfectly safe - as long as the root code
is in a separate binary where the cached password cannot be used to
compromise the whole app (which is easy to exploit).
Michael
_______________________________________________
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