Why does the system have /etc/sudoers.d? How should I edit it?

Question

Last time, I asked about the risk of these (in /etc/sudoers):

user_name ALL=(ALL) /usr/bin/vim /etc/httpd/confs/httpd.conf
%group_name ALL=(ALL) /usr/bin/vim /etc/httpd/confs/httpd.conf

While I was thinking about this problem, I found /etc/sudoers.d directory. Files in the directory should have similar functions to /etc/sudoers (meaning the scripts above are still problematic even in /etc/sudoers.d), and however one article said we should not use the directory because we cannot use visudo to edit files in it. That is, we lose the right to use sudo if we make a mistake in the directory.

If that is true, why do we have /etc/sudoers.d? Or do we have a good way to edit files in /etc/sudoers.d?

Answer 1

Yes, you can use visudo to edit those files. All that you have to do is specify the name of the file that you want to edit with the -f option. For example:

visudo -f /etc/sudoers.d/somefilename

Or, if needed:

sudo visudo -f /etc/sudoers.d/somefilename

Documentation

From man visudo:

-f sudoers
Specify and alternate sudoers file location. With this option visudo will edit (or check) the sudoers file of your choice, instead of the default, /etc/sudoers. The lock file used is the specified sudoers file with ".tmp" appended to it. In check-only mode only, the argument to -f may be "-", indicating that sudoers will be read from the standard input.

In summary:

1. Syntax: Both visudo and visudo -f perform the same syntax checking.

2. Permissions/Ownership: As a feature added to assist the administration of large systems, files edited under visudo -f are not checked for ownership or permissions: this allows syntax checking of a file offline or as part of a revision control system.

Why use /etc/sudoers.d/

Typically /etc/sudoers is under control of your distribution's package manager. If you have made changes to that file and the package manager wants to upgrade it, you will have to manually inspect the changes and approve how they are merged into the new version. By placing your local changes into a file in the /etc/sudoers.d/ directory, you avoid this manual step and upgrades can proceed automatically.

When does sudo ignore a file in /etc/sudoers?

If your /etc/sudoers file contains the line:

#includedir /etc/sudoers.d

then sudo will read files in the directory /etc/sudoers.d.

Exceptions are:

1. Files whose names end in ~
2. Files whose names contain a . character

This is done (a) for the convenience of package managers and also (b) so that backup files from editors are ignored.

Important: Note that exception 2 above is quite general, and means that seemingly reasonable file names like mysudo.conf or mysudo.txt will be ignored because . is in the name.

Answer 2

Changes made to files in /etc/sudoers.d remain in place if you upgrade the system. This can prevent user lockouts when the system is upgraded. Ubuntu tends to like this behavior. Other distributions are using this layout as well.

It has been my experience that the rules on files in this directory are looser than for /etc/sudoers. This has included:

• Mistakes in the file did not cause sudo to fail. However, the file was ignored.
• Permission rules appear less strict. It allows the applicable group or other to read the file. I don't believe that was possible with /etc/sudoers. Write permissions must be restricted to root to maintain security. The current Ubuntu version of sudo allows read permissions for group or other. (This capability allows sudo access to be audited using without requiring root access.)

The visudo command only defaults to /etc/sudoers. It will edit and verify any file you specify with the -f option. I use this capability to edit files which will be automatically installed as /etc/sudoers or into /etc/sudoders.d. However, definitions from other files may not be found. It is best to make the file independent.

The ability to have stand-alone files makes it simple for an application to enable sudo capability on installation and remove them when it is un-installed. Automated configuration tools can also use this capability.

I have used this capability to isolate changes required to grant access to specific user groups on specific systems.

Answer 3

why do we have /etc/sudoers.d?

Because it's easier for automated tools (such as Chef or Puppet) to drop individual files into this directory, rather than making changes to /etc/sudoers, which might be fragile.

The files in /etc/sudoers.d are (in effect) concatenated. You'll see several other instances of this pattern in /etc, such as /etc/cron.d and /etc/logrotate.d.

Answer 4

Another benefit of using visudo -f as mentioned in some answers is there is a corresponding option -c or --check that verifies you don't have invalid information in a sudoers.d file or any other file you might want to put in sudoers.d. This is REALLY handy in the cases mentioned with automated tools, as you can run e.g.

sudo visudo -c -q -f /home/myuser/mysudoers && \
sudo chmod 600 /home/myuser/mysudoers && \
sudo cp /home/myuser/mysudoers /etc/sudoers.d/mysudoers

This silently checks the file (no output due to -q) and only if that does NOT return an error (exit 1 means an invalid sudoers file) then it will copy the file into sudoers.d, this way you can create the file and work on it without having to make it right the first time (using sudo visudo -f /etc/sudoers.d/myfile has to succeed or it discards the content if you don't fix it).

Also, a word of caution regarding these statements from the other answers.

It has been my experience that the rules on files in this directory are looser than for /etc/sudoers. This has included:

Mistakes in the file did not cause sudo to fail. However, the file was ignored. Permission rules appear less strict. I allow the applicable group to read the file. I don't believe that is possible with /etc/sudo.

Files in /etc/sudoers.d are required to adhere to the same syntax as /etc/sudoers, because under the covers the system simply concatenates together all the files with the last one in "winning" if there are multiple entries for the same singular setting.

If the permissions are horribly incorrect (world writable) on files in /etc/sudoers.d/ then they are ignored, this may be what caused the invalid files to get overlooked, otherwise you can seriously break the sudo command by having an invalid sudoers.d file with correct permissions.

You can allow the sudoers files to be world readable, if you accidentally allow 'other' the write permission you need to sudo as another user or from a root terminal run this command. This can also break if the file is owned by someone other than root:root.

sudo chmod 644 /etc/sudoers.d/mysudoers
sudo chown root:root /etc/sudoers.d/mysudoers

I just confirmed that if I run chmod o+w /etc/sudoers.d/vagrant I can no longer sudo as the vagrant user, it prompts me for my password and then fails.

When I ran sudo -l to view the applied command permissions as another valid sudo user, I also received a warning about the file permissions. This is the same command I used to confirm that the 'vagrant' user lost sudo when I applied o+w permissions to the file giving that user sudo permissions.

Answer 5

Just a short addon to any general answer... none of the other answers fixed my issue, which was that order matters.

If your lines work in sudoers but not sudoers.d, try moving the #include around, or changing the order of your sudoers.d files (by prefixing with a number). It seems that the most specific thing should be first in the file.

I had something like:

somebody ALL=(ALL): somecommand
somebody ALL=(someoneelse) NOPASSWD: somecommand

And the 2nd one had no effect because the first already matched. NOPASSWD is not a condition, but some way to modify the action.

And it wasn't obvious because it was not in a single file, due to the sudoers.d directory.