'Sudo NOPASSWD not registering/working/showing
Sudo version: 1.7.2p1
I have the following (sanitised) lines in my sudoers file (at the end of the file):
Runas_Alias GROUPALIASNAME = user1,user2, user3
Cmnd_Alias APP = /path/to/binary/setup -f *, /path/to/binary/patchbinary
%groupname
ALL=(root)NOPASSWD:SOFTWARE,(GROUPALIASNAME)NOPASSWD:APP
If I run "sudo -ll" as a user from %groupname (user3) I get the following:
Sudoers entry:
RunAsUsers: root
Commands:
NOPASSWD: /bin/rpm, /usr/bin/up2date, /usr/bin/yum
RunAsUsers: user1, user2, user3
Commands:
/path/to/binary/setup -f *,
/path/to/binary/patchbinary
I can't seem to get the second "nopasswd" entry to work. I've tried removing all whitespace, adding whitespace. I've tried "NoPasswd:all" which just makes it give "all" rather than "nopasswd:all". I know the rule is matching because clearly I can see the very specific entries expanding. The entry being at the end should rule out any conflicting rules. Any ideas or suggestions on diagnosing this? Unfortunately its a 'secure' machine so applying patches/updating sudo isn't an option. **The reference to "SOFTWARE" is just a default sudoers entry.
EDIT: For now I have worked around the issue by splitting the 1 line into 2 lines. I made no other modifications than to insert a line break with %groupname ALL= and it now correctly shows the right to execute the command with no password. However it still requires a password.
Solution 1:[1]
To aide debugging and maintainability you should split your rules:
%groupname ALL=(root) NOPASSWD: SOFTWARE
%groupname ALL=(GROUPALIASNAME) NOPASSWD: APP
Splitting your rules onto different lines makes it clearer what you are trying to do.
Ensure that the user you are trying to run sudo as, is in %groupname.
Ensure that you are using something like sudo -u user1 (etc) so the Runas_alias is actually effected.
The other thing you need to do, is if you are testing changes as the destination user, if you just added your user to %groupname, you need to log out and log back in for the group add to actually work.
Solution 2:[2]
This isn't the issue in your case specifically, but I came across this question when trying to troubleshoot my own issue.
In my case, I had created a new file in the sudoers.d directory. Specifically, it was named 100-backupreader-privileged-scripts.conf. Nothing seemed to be working, and I spent quite a bit of time searching and trying all sorts of various syntax, to no avail.
Then I read this line in the manpage (man 5 sudoers)
The #includedir directive can be used to create a sudoers.d directory that the system package manager can drop sudoers file rules into as part of package installation. For example, given:
#includedir /etc/sudoers.d
sudo will suspend processing of the current file and read each file in /etc/sudoers.d, skipping file names that end in ‘~’ or contain a ‘.’ character to avoid causing problems with package manager or editor temporary/backup files.
Turns out you can't name a file something.conf in the sudoers.d folder. I renamed the file to remove the period and everything started working!
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | |
| Solution 2 | maples |
