Re: Authorization without permanent setuid on helper
Re: Authorization without permanent setuid on helper
- Subject: Re: Authorization without permanent setuid on helper
- From: John Davidorff Pell <email@hidden>
- Date: Fri, 21 Jan 2005 20:48:25 -0800
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.
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.
JP
--
"NOTICE: This E-mail (including attachments) is covered by the
Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is
confidential and may be legally privileged. If you are not the intended
recipient, you are hereby notified that any retention, dissemination,
distribution or copying of this communication is strictly prohibited,
Please reply to the sender that you have received the message in error,
then delete it. Thank you."
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