'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