We use the #include
feature in the sudoers file for organizing our sudo rules on a per-application basis.
Our sudoers set up looks kinda like this:
/etc/sudoers
-> #include /usr/local/etc/sudo/sudoers.master
-> #include /usr/local/etc/sudo/app1.sudo
-> #include /usr/local/etc/sudo/app2.sudo
-> #include /usr/local/etc/sudo/<...etc...>.sudo
/usr/local/etc
is a directory we sync across all of our servers.
Sometimes we need host-specific sudo rules, so we put those directly into /etc/sudoers. Everything global goes into those centrally synced files.
When I run visudo
to edit the local sudoers, it opens /etc/sudoers
in vi without a problem. When I save my changes, I get prompted with:
"/etc/sudoers.tmp" XX lines, XXXX characters
press return to edit /usr/local/etc/sudo/sudoers.master:
visudo: can't stat /usr/local/etc/sudo/sudoers.master: Bad file number
And then visudo just exists (exit code 1).
The syntax for the sudoers.master
and appX.sudo
files all check out.
What is causing visudo to fail to follow through with opening the sudoers.master
file that was included via the #include
at the end of the base sudoers?
I'm seeing this behavior on AIX, Linux, and Solaris.
As a work-around, is there a way to tell visudo to just not follow any #include
directives, and only edit the primary file?