8

Running a fresh install of Ubuntu server 16.04.1, I tried to add a file in /etc/sudoers.d/ to give one user root privileges for a certain command.

I added the file /etc/sudoers.d/servicetest with the following content:

servicetest ALL = (root) NOPASSWD: /bin/systemctl status *

The file /etc/sudoers is left untouched. It contains #includedir /etc/sudoers.d as the last line. This setup is unfortunately not working, when executing an appropriate command with sudo as the user servicetest, I am still asked for the password. However, if I move the content of the file /etc/sudoers.d/servicetest to the end of /etc/sudoers, everything is working as expected.

What could be the cause of this issue? How can I get files in /etc/sudoers.d/ working?

  • 2
    Maybe sudo doesn't accept files with the wrong permissions for security reason (just a guess). What are the /etc/sudoers.d/servicetest permissions? – IanC Oct 27 '16 at 21:48
  • 3
    ^^^ +1 in fact the /etc/sudoers.d/README file says "all files in this directory should be mode 0440" – steeldriver Oct 27 '16 at 22:58
7

Apparently, the files that are included in the /etc/sudoers file must have 0440 permissions for security reasons. That way only root can edit the file and only the owner and members of the owner group can read it, making it less likely that the file will be used as an attempt to escalate privileges.

You can check the requirements on the included file on /etc/sudoers.d/README, but two other requirements are that the filename shouldn't start with a . (hidden files) or end with a ~ (convention for backup files).

Credits to @steeldriver for confirming the theory and finding the /etc/sudoers.d/README file!

  • 2
    And that's why one should use visudo -f /etc/sudoers.d/foo while editing files in /etc/sudoers.d. – muru Oct 28 '16 at 4:26
  • 1
    Thanks! I did not consider the permission checks to be that harsh (especially since the README says should be and not must be). root:root 0440 and root:root 0640 doesn't make a difference for me, but it looks like it does for sudo ;) – Cybran Oct 28 '16 at 5:57
  • 1
    Unfortunately, that was not the cause. I just tested it with corrected permissions (root:root 0440) and have the same problem as before. – Cybran Oct 28 '16 at 12:06
  • sudo still need to be used in the cli for the new privileged user, otherwise, password will be asked to enter – Samir Sabri Jan 15 at 9:01
3

The problem was not, as answered by IanC, caused by the file permissions (sudo happily accepts a file owned by root:root 0644, as I can confirm now, although it should of course be root:root 0440 for security reasons!), but by a newline at the end of the file which was preceded by a windows-style line ending (\r\n).

sudo only accepts \n as line endings.

  • Nice that you solved your problem! Did you edit the file in windows? Was curious on how you ended up with the windows newline! – IanC Oct 28 '16 at 15:55
  • Yes, I edited a template for the sudoers file in Windows and transferred it via ssh to the Ubuntu machine. And, of course, forgot to convert line endings before doing so. My own stupidity :( – Cybran Oct 28 '16 at 16:04
2

In my CentOS 7, the system would not recognize the file if it had a dot in its name. For instance:

/etc/sudoers.d/user.perms                  # This file doesn't work
/etc/sudoers.d/userperms                   # This file does
  • I've run into the same issue on Ubuntu 18.04, removing the dot and ensuring permissions were set to 0440 and all is well. – Joe Dec 30 '19 at 14:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.