begin  quoting James G. Sack (jim) as of Tue, Sep 12, 2006 at 11:24:39AM -0700:
[chop]
> Quick answer:
> 1. not all users are permitted to use sudo
> 2. those who do can be restricted in various ways
> 3. every sudo command is logged, which IMHO is one of the biggest 
> benefits of using sudo. I want to be able to look up what I did!
 
Good answer, too.

> There is bit of an interesting chicken-or-egg situation here.
> 
> With no root password,

(And a null-passwords-not-allowed policy...)

>                        the _only_ way to execute with root's privileges 
> is via sudo. But a user can only perform sudo if there is an entry for 
> that user (or a group he is a member of) in the /etc/sudoers control 
> file. But only root can edit the sudoers file and/or add users to groups 
> -- see the dilemma?

Been there, done that, spent far too much time mucking about trying to
fix it.  Ended up booting into a rescue mode, mounting the disk, and
manually editing /etc/sudoers.

> Systems like ubuntu setup an admin group with an entry in the 
> standard-distribution sudoers file, and then on installation, ask for 
> and create a user account (which is made a member of the admin group). I 
> don't remember whether or not they come right out and say that that 
> first user is an admin during the install.

That's the default assumuption in OS X as well. First user ==
administrator.

> Ummm, the only _other way_ is via ssh using pki authentication.

Um... Kereberos or LDAP?

> Err..now of course, there's always booting into single user mode or 
> accessing the  filesystem on the hd by booting a livecd, or plugging the 
> hd into another system, or..

Yup.

Encrypted filesystems help avoid that, but if you forget the
passphrase...

> Well, maybe someone else would like to add some _more only other_ ways.

Heh.

-- 
_ |\_
 \|


-- 
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list

Reply via email to