On 10/26/22 1:42 AM, Ramon Fischer wrote:
and your user is able to synchronise your clock again.
I'm not sure that will work as hoped. See my other reply about PTY and
testing the commands at the command line for more explanation of what I
suspect is happening.
I do not know, what the developers were thinking to encourage the user
to edit a default file, which gets potentially overwritten after each
package update...
To the sudo developers, the /etc/sudoers file is *SUPPOSED* *TO* /be/
/edited/.
The sudo developers provide the sudo (et al.) program(s) for your use
and /you/ provide the configuration file(s) that it (they) use.
It is natural for the /etc/sudoers file to be edited.
To me the disconnect is when people other than the sudo developers
distribute the /etc/sudoers file and expect that it will not be edited.
What are end users / systems administrators to do if the default file
has something like the following enabled in the default /etc/sudoers
file and the EUs / SAs want it to not be there?
%wheel ALL=(ALL:ALL) ALL
They have no choice but to change (edit / replace) the /etc/sudoers file.
Especially if other parts of the system rely on the wheel group and not
putting users in it is not an option. -- The above line *MUST* be
taken out, thus the /etc/sudoers file *MUST* be edited.
Unix has 50 years of editing files to make the system behave as desired.
Modularization and including other files is nice /when/ /it/ /works/.
But there are times that modularization doesn't work and files *MUST* be
edited.
"etc-update" helps to have an eye on, but muscle memory and fast fingers
are sometimes faster.
How many levels of safety do you suggest that we put in place?
What if someone were to put the following into /etc/sudoers.d/zzzzzzzzzz
ALL ALL=(ALL) !ALL
}:-)
This is the best way. Try to be as precise as possible, but be aware of
wildcards![1]
The /etc/sudoers syntax can be tricky to master. But it can also be
very powerful when done correctly.
--
Grant. . . .
unix || die
