Sudoers.d Permissions denied

Question

I am running ubuntu 14.04 in DardDrive. I was taking the Steps for Setting up and Running sudo located here http://snag.gy/JAGgt.jpg. But every I type sudo "whatever" as user ($), I get the following message:

 sudo: unable to stat /etc/sudoers.d/README: Permission denied
 sudo: unable to stat /etc/sudoers.d/ken: Permission denied.

so I leveled up as root and did ls -l | grep sud. See the following:

root@ken-:/etc# ls -l | grep sud
-rw-r-----  1 root root       745 mar 19 12:11 sudoers
drwxr-----  2 root root      4096 mar 19 14:53 sudoers.d

Based on the instructions on how to configure sudo, I should make a directory named same as my username in sudoers.d directory and in that file I have to just type ALL(ALL)LL on the user name. but, I also did a chmod 440 on that file, which makes it look like this:

root@ken-Inspiron-5558:/etc/sudoers.d# ls -l
total 8
-r--r----- 1 root root  22 mar 19 14:53 ken
-r--r----- 1 root root 958 mar 19 12:16 README

At this point when I level down using sudo su ken, and want to get into sudoers.d I keep getting the permission denied statement.

I am not even able to access sudoers.d as user, see this:

ken@ken-Inspiron-5558:/etc$ cd /etc/sudoers.d/
 bash: cd: /etc/sudoers.d/: Permission denied-

Solution 1

First, based on the instructions it's ALL=(ALL) ALL , so there's one mess up.

Second , instructions say If your system does not already have sudo set up and enabled , which you really should have checked before doing the rest.

Third, just remove that ken file. Your username is added to sudo group automatically during installation (if that's the username you picked during installation of course, and not created manually).

Finally, look at your /etc/sudoers.d permissions:

root@ken-:/etc# ls -l | grep sud
-rw-r-----  1 root root       745 mar 19 12:11 sudoers
drwxr-----  2 root root      4096 mar 19 14:53 sudoers.d

A directory requires execute permissions bit set in order to navigate into it. You cannot navigate into the directory because only the owner( root ) has x set for it (Related post on serverfault demonstrates that well enough). So your navigation to /etc/sudoers.d issue has nothing to do with sudo but with folder permission bits

But if you are still unconvinced heres a demo on a directory, owned by my user, in my home folder.

$ ls -ld testdir                                               
drwxrwxr-x 2 xieerqi xieerqi 4096 Mar 17 16:34 testdir/
$ chmod -x testdir
$ cd testdir
/bin/mksh: cd: /home/xieerqi/testdir: Permission denied

Solution 2

You should have not added anything to /etc/sudoers.d/!
This is simply unnecessary and dangerous (as you see). All admin users (including the default user account that gets created during the installation) are already allowed to use sudo to run commands with root privileges.

Remove the file /etc/sudoers.d/ken again and revert all changes you might have done to /etc/sudoers.d.
You can use pkexec as temporary replacement for sudo to fix the issues while that does not work:

pkexec rm /etc/sudoers.d/ken

---

Admin users on Ubuntu are defined by their group membership in the sudo (formerly admin) group.

When you add new admin users through the Unity Control Center GUI, it will take care of those group memberships automatically.

When you add a new user from the terminal using sudo adduser USERNAME, it will not be a member of any additional group. In this case, you have to add those two groups manually to make the account an administrator that is allowed to use sudo:

sudo adduser USERNAME sudo

---

And in the rare case where you really would have to edit /etc/sudoers or a file in /etc/sudoers.d/, never do that manually but **always use sudo visudo to edit it! This command will verify the files and check for errors before applying the changes and prevent leaving you with a ruined sudo command.

Comments

[QwertyChouskie]

Why are you trying to manually set up sudo? sudo is automatically set up on Ubuntu systems in almost all circumstances.

[muru]

Please don't post screenshots of text. Copy the text here. I don't see any reason you should be able to access /etc/sudoers.d as a normal user.

[Byte Commander]

Normal users may not read or modify the /etc/sudoers* files and directories, this is correct and intended for security reasons.

[Byte Commander]

And I have no idea for what Linux distribution the guide you describe is intended, but it has definitely nothing to do with Ubuntu! Ubuntu comes with everything already configured and ready to use.

[Sergiy Kolodyazhnyy]

See my answer guys, his directory navigation issues have nothing to do with sudo

[Byte Commander]

Yes, you messed up your sudo command by adding a wrong configuration file. Use pkexec rm /etc/sudoers.d/ken.

[Ken Sandoval]

I did, thanks, but, now, it is weird, because, when I level down to my ken user, and I do $sudo ls, I actually get my list of files, for example, in my home directory, I get the following: ken@ken-Inspiron-5558:~$ sudo ls sudo: unable to stat /etc/sudoers.d/README: Permission denied Photos Videos Music Files Personal. This is like if I was getting denied permissions on a README file but the permissions on the README file are the following: _____________# ls -l /etc/sudoers.d/README -r--r----- 1 root root 958 mar 19 12:16 /etc/sudoers.d/README

[Byte Commander]

Did you modify the content of the readme file? When you open it (as root), is there any line in it that does not start with a # sign? Did you make any modifications to /etc/sudoers?

[Ken Sandoval]

Can you take a look at this: snag.gy/lnJqV.jpg. it is the README file which I had to open as root of course using vim. here are the permissions of this file snag.gy/Zvwm8.jpg Should I change it ?

[Byte Commander]

@heemayl I disagree with your edit. When I check the group memberships of the default admin user (UID 1000) on all of my machines, none of them is member of an admin group. My current group memberships on this machine are bytecommander adm cdrom sudo dip plugdev lpadmin sambashare kvm libvirtd. There doesn't even exist any admin group. Therefore I rolled back your edit. If you want to discuss it, please reply to this comment or in chat.

[heemayl]

You don't get it..check sudo grep admin /etc/sudoers ..admin group is legacy, it was before sudo group was introduced..it is just kept for legacy's sake..by default no user is a member of the group (check getent group admin), although you can assign one....also adm is just for logs permission..no offense but you should do your homework first honestly before reverting back my edit..

[Byte Commander]

@heemayl Okay, the adm group is probably my mistake. But I still have no admin groups on any machine. sudo adduser bytecommander admin reports back that the admin group does not exist. Also it's not in /etc/group. That's at least the case on 15.10.

[Sergiy Kolodyazhnyy]

I'm on 14.04, and admin isn't created ( by default ), but it's part of /etc/sudoers file, because admin group as far as I understand from this exists for backward compatability with older systems ( before 12.04 LTS ) where admin group was the superuser type of group. adm group apparently exists only for being able to read logs. In a nut shell, adm isn't related to sudo, admin is in /etc/sudoers for compatability. Hope that helps ?

[Byte Commander]

@Serg Thanks for the nice explanation and linked reference. Now I understand what heemayl wanted. But as the admin groups seems abandoned since 12.04 inclusive, it's probably better not to use it.

[Sergiy Kolodyazhnyy]

@ByteCommander Well , it could serve as a workaround, but i really see no reason why OP cannot su to root and purge sudo with apt-get , then reinstall it (if that can help the situation of course)

[Byte Commander]

I don't like your answer, because there's no need to add a user to the /etc/sudoers file to allow him to become root using sudo. That's what the sudo group (formerly admin group, as I just learned) is for in Ubuntu. Also, one should never edit /etc/sudoers directly but always only using the command visudo as root (or with sudo), because that only saves the changes if the new file would parse correctly and does not contain syntax errors that would break the entire sudo system. Also, why use NOPASSWD!? That's a huge security risk!

[Byte Commander]

@Serg Dunno if that works... And I'm not going to try it.

[Prakash]

correct in the sense that sudoers file should be edit as visudo and not vi only. That is why I have not edited sudoers file itself (check out above again). If you are concern about security risk then you shouldn't use NOPASSWD and limit sudo commands.

[Byte Commander]

Syntax errors in files in /etc/sudoers.d/ also break the entire sudo sytsem, as you can see in the question. All the files there are simply appended to /etc/sudoers and then the whole thing is evaluated at once.

[Byte Commander]

Correct catch that #includedir /etc/sudoers.d is commented out, but Ubuntu never adds single user names to /etc/sudoers automatically. The privileges are granted through membership of the sudo group only by default.

[Sergiy Kolodyazhnyy]

@ByteCommander Thanks, good catch. What I mean is that when you install Ubuntu and create the username , you will be added to sudo group automatically.

[Derek Veit]

The pound sign in #includedir does not make it a comment. See man sudoers.

[Sergiy Kolodyazhnyy]

@DerekVeit Didn't know that. Thanks. I'll edit my answer in a moment