Opened 19 months ago
Closed 19 months ago
#15730 closed defect (fixed)
Rename files in /etc/sudoers.d so that we are sure that they load in order
|Reported by:||pierre||Owned by:||Bruce Dubbs|
If two files in /etc/sudoers.d set the same variable, the second one in ascii lexicographic order takes precedence. This may be not what we want. So a good practice would be to prefix all the filenames in /etc/sudoers.d with two digits, so that sorting them is easy.
The book creates some of those files, and names them "randomly". For example /etc/sudoers.d/sudo, created on the sudo page, is high in alphabetical order, so that its settings may win over whatever a user may set...
Change History (6)
comment:1 by , 19 months ago
comment:2 by , 19 months ago
There are two use cases that have hit me directly or indirectly, which show that doing nothing may lead to unwanted effects.
The first one is that I have a file named pierre in /etc/sudoers.d giving user pierre the ability to run sudo without password. But because of the content of the sudo file, if user pierre is in group wheel, he has to enter his password anyway (the "%wheel" stanza takes precedence).
The second one was for a user on #lfs-support: he tried adding:
Defaults secure_path = ...:/opt/rustc/bin
with ... set to a lot of other irrelevant directories. This is because sudo make install does not work for librsvg if we use the book's configuration: cargo is not found.
But he put that stanza in a file named /etc/sudoers.d/rust, so that it was overridden by /etc/sudoers.d/sudo.
What I propose is some advice from sudoers(5):
[...]Files are parsed in sorted lexical order. That is, /etc/sudoers.d/01_first will be parsed before /etc/sudoers.d/10_second. Be aware that because the sorting is lexical, not numeric, /etc/sudoers.d/1_whoops would be loaded after /etc/sudoers.d/10_second. Using a consistent number of leading zeroes in the file names can be used to avoid such problems.
So it seems to me that it is "good practice". Shouldn't we try to teach "good practice"?
comment:3 by , 19 months ago
I think adding a caution should be sufficient.
For secure_path, it can be disabled and the user can then use sudo's -E option to export the user's environment to the sudo environment.
Try this in sudoers or a file in sudoers.d/:
Personally I don't use any files in sudoers.d/ because I am the only user on the system. That directory is really for distros to drop in files.
My sudoers file looks like:
Defaults !secure_path root ALL=(ALL:ALL) ALL bdubbs ALL=(ALL) NOPASSWD: ALL
But that root line is not really needed because I add --disable-root-sudo when I build sudo anyway. Other options that are useful to me include:
--with-ignore-dot \ --enable-shell-sets-home \ --enable-noargs-shell \ --with-logfac=auth \ --without-pam \ --without-sendmail
The user also has the option of not using --with-secure-path when building sudo.
comment:4 by , 19 months ago
Well, using !secure_path preserves the user's PATH, I guess, but it does not add /usr/sbin to the PATH.
I do not agree to just put a warning: we use that directory in the book. Maybe we shouldn't. But if we do, we should have a proper naming for files.
/etc/sudoers.d/sudo should be renamed /etc/sudoers/00_sudo, at least, so that it is overridden by any file whose name begins with a letter. I agree that the other files just add to env_keep and can be read in any order.
comment:5 by , 19 months ago
|Status:||new → assigned|
comment:6 by , 19 months ago
|Status:||assigned → closed|
Added configuration comments at commit 193bdf3d1237646ea3e5076b65a522072e09bbf6
It is not clear to me that this is necessary. You can make the same arguments for /etc/profile.d.
For sudoers.d, every entry except the one the sudoers page is of the form:
Unless someone makes a mistake and leaves off the +, nothing gets overwritten.