* Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!
@ 2022-10-26 16:38 99% ` Grant Taylor
0 siblings, 0 replies; 1+ results
From: Grant Taylor @ 2022-10-26 16:38 UTC (permalink / raw
To: gentoo-user
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
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2022-10-26 2:34 [gentoo-user] Update to /etc/sudoers disables wheel users!!! Walter Dnes
2022-10-26 3:04 ` Ramon Fischer
2022-10-26 6:31 ` Walter Dnes
2022-10-26 16:38 99% ` Grant Taylor
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox