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
