As a sequel to the first post I made to this blog, I’ve found myself tackling this same thing with every macOS release. Today, however, I discovered a line in /private/etc/sudoers that I hadn’t noticed before:
## Read drop-in files from /private/etc/sudoers.d
## (the '#' here does not indicate a comment)
After some research, I discovered that you can drop a file in /private/etc/sudoers.d (a directory), and, as long as the syntax is correct, it will merge those with the main sudoers file. In the event of a conflict, the last rule that applies takes effect – and, the main sudoers file is read first, so you can essentially override behavior by dropping a file into the sudoers.d directory. Awesome!
I’ve posted the working code to my GitHub repository. In the event that you want to make a change, be sure to check the file before packaging it up – or you risk breaking sudo:
/usr/sbin/visudo -csf /path/to/your/file
Because you might not want techs getting used to “being root” I would suggest you prevent your diagnostic user from becoming root with NOEXEC: and you log all output with LOG_OUTPUT:
Nice, thanks! I really need to do some more digging into what’s possible with the sudoers file, this looks like stuff we’d want to use in our production environment.
Thanks for the post. You might want to checkout our sudo manager
We use it in our environment to allow scripts, applications & installers run that need sudo by standard users.
Thanks, Richard! The part that caught my interest was being able to deploy individual files to the sudoers.d directory, rather than modifying the sudoers file directly. It looks like the “include” line was added in 10.10, but the directory itself didn’t exist until 10.12 (you can probably create the directory on 10.10 and 10.11 and it’ll behave the same way).
It’s much less complex to deploy a file with Munki to sudoers.d, than to modify the sudoers file (and check it with visudo to make sure it’s OK).