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

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.

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.

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.