Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!

[Grant Taylor <gtaylor@gentoo.tnetconsulting.net>]

On 10/26/22 12:31 AM, Walter Dnes wrote:
> My regular user has script "settime" in ${HOME}/bin
> 
> #!/bin/bash
> date
> /usr/bin/sudo /usr/bin/rdate -nsv ca.pool.ntp.org
> /usr/bin/sudo /sbin/hwclock --systohc
> date
> 
> /etc/sudoers.d/001 has, amongst other things, two lines...
> 
> waltdnes  x8940 = (root) NOPASSWD: /sbin/hwclock --systohc
> waltdnes  x8940 = (root) NOPASSWD: /usr/bin/rdate -nsv ca.pool.ntp.org
> 
> User "waltdnes" is a member of "wheel".  If the "wheel" line is 
> uncommented in /etc/sudoers, sudo works for me.  If the "wheel" 
> line is commented, then sudo breaks for my regular user.

Please try running the two sudo lines from the script as is on the 
command line as the waltdnes user.  I'm wondering if the problem is 
potentially related to something else, namely sudo wanting to read from 
a terminal (PTY) in some configurations.

I believe there is a non-zero chance that the commands allowed via the 
/etc/sudoers.d/001 file will work as entered.  But that running sudo 
from within a script, as opposed to on the command line, /may/ be the 
source of problems.  --  Divide and conquer the problem.

> There seem to be two different approaches here.  The loose approach 
> is to allow a user to run "sudo <whatever I damn well want>".

This seems to be -- what I refer to as -- the distribution default. 
E.g. get people to run things through sudo vs running things through su 
or running directly as root.

> A more locked down approach allows regular users to run "sudo <very 
> specific command>".

This is -- what I refer to as -- the (more) enterprise approach.  It 
also seems to be the next evolution of the distribution default wherein 
people want to start restricting what can and can't be run via sudo.

The enterprise approach also tends to come more into play as you use 
sudo to run things as users other than root; e.g. run RDBMS commands as 
the Oracle user or backup commands as the Tivoli user.

> This guards against "fat-finger-syndrome".

I think it's more than protection against fat-finger-syndrome.  After 
all, unless the sudoers file(s) is (are) *EXTREMELY* specific down to 
and including command parameters / options, you can still fat-finger 
command parameters / options.

When you start separating duties and who is allowed to do what is when 
you start to see the more locked down enterprise methodology.

> I go with the more locked down approach

I use the distribution default on my personal systems where I'm 95% of 
the use case.

I use the enterprise method on work systems where we have multiple 
people with different skill levels doing different tasks.

Aside:  One advantage of the enterprise method is that you can allow a 
command as one target user (Oracle) but not the (default) root user. 
Thus helping protect against people omitting a critical option.  -- 
Many things, e.g. Oracle RDBMS, get rather upset when commands 
(accidentally) change the ownership of files when run as the wrong user.



-- 
Grant. . . .
unix || die