Suddenly I'm running into permission problems when I issue commands as root via sudo.

I can create files in my home directory using normal permissions, so something like this works for example:

vi /home/mike/test.txt

But the equivalent command run using sudo doesn't work:

sudo vi /home/mike/test.txt
"test.txt" E212: Can't open file for writing

This is just one example, all commands using sudo fail for permission reasons.

I'm assuming because I can write using normal permissions that it's not an issue with the file system being read-only. It's also not limited to file writes, commands like "sudo visudo" will fail for permission reasons as well. I am not aware of any recent changes to the server that would have caused this ("sudo" had been working fine for this user for the 8 or so months it's been up). A hard reboot hasn't solved the issue.

Server is: Ubuntu 8.04.2 LTS (hardy)

Any ideas or help would be greatly appreciated!

  • 2
    are you sure you don't want to do a 'sudo vi /home/mike/test.txt' or is it a typo? – lexu Sep 14 '09 at 6:22
  • Typo ;) Sorry, fixed. – user20136 Sep 14 '09 at 13:53
  • What does ls -ld /home/mike say? – Roger Lipscombe Sep 14 '09 at 14:09
  • "drwxr-xr-x 7 mike mike 4096 Sep 14 13:33 /home/mike" Note: this isn't just an issue with the user's home folder, any execute or write commands run using root are returned with "permission denied", even on files owned by root itself. – user20136 Sep 14 '09 at 14:24

Could you run

sudo -s

And post the output? I want to see if it's actually making you the user you think.

Also, try

sudo cat /etc/sudoers

The output of id here is quite enlightening. When you ran sudo -s, you were given a UID of 1, while the only UID that the kernel will recognize as having root privileges is UID 0.

Try running

getent passwd | grep ':0:'

and see if any entries have that 0 in their first numeric field, the UID. Whatever account that is is the real superuser on the system, while root is a fake. Once you know the name, you can try

sudo -s -u username

to get a shell as that user.

You should also post the output of

getent passwd root

The bigger issue here is how such a condition came to pass.

Is this machine offering any network services? If so, someone may have broken into it and taken it over. In that case, you should probably back up the data, do a clean re-install, and audit anything that goes back on it.

If it's more of a personal machine, might there be a knowledgeable prankster who's had access to it recently?

Edit: your comment to another answer suggests that this is a server. I would highly recommend taking it offline ASAP and imaging its disks for forensic purposes. Unless you can identify a benign cause for this in short order, you've probably had your server cracked.

  • sudo -s; id output: uid=1(root) gid=0(root) groups=0(root) – user20136 Sep 14 '09 at 15:13
  • sudo cat /etc/sudoers output: # /etc/sudoers # # This file MUST be edited with the 'visudo' command as root. # # See the man page for details on how to write a sudoers file. # Defaults env_reset # Uncomment to allow members of group sudo to not need a password # %sudo ALL=NOPASSWD: ALL # Host alias specification # User alias specification # Cmnd alias specification # User privilege specification mike ALL=(ALL) ALL root ALL=(ALL) ALL – user20136 Sep 14 '09 at 15:13

can you still become root using

sudo su -

then, does

cd /home/mike
vi test.txt


  • "sudo su -" seemingly does nothing, "sudu -i" does give me root though but the permissions problem persists. – user20136 Sep 14 '09 at 13:37
  • To clarify "sudo su -" doesn't make me root. Should it? "sudo -i" does...output from "sudo -i; id": uid=1(root) gid=0(root) groups=0(root) – user20136 Sep 14 '09 at 15:41
  • Yes, "sudo su -" should make you root, just like sudo -i. There may be a problem with your passwd/shadow files if you can't get to root with that -- locked password, no home directory, shell set to /bin/false, or something similar. Try "getent passwd root", and post the result – Ian Clelland Sep 15 '09 at 6:52

I am wondering if the /home directory is an NFS mount. In this case, the root user has the permission of the 'other' catagory as its permissions on the NFS mount are as the user nobody/nobody and not the root user.

  • Thanks. Do you have any guidance on how best to test whether this is the case? – user20136 Sep 14 '09 at 16:16
  • It doesn't seem to be the case. "stat -f -L -c %T /home/mike" outputs: ext2/ext3 – user20136 Sep 14 '09 at 16:29
  • df -T tells me it's of Type ext3 – user20136 Sep 14 '09 at 16:30

Is the sudo binary SUID root?

ls -l $(which sudo)
  • is /home or /home/mike same partition as "/" mount?
  • could you also post output from lsattr /home/mike/test.txt command ?
  • Yes, /home is the same partition as "/". Output from lsattr /home/mike/test.txt: "------------------ /home/mike/test.txt" – user20136 Sep 14 '09 at 14:47
  • weird, ok let's use big tools, could you post output file of: " strace -ff -F -s256 /path/to/vi test.txt > output 2>&1 " – savecore Sep 14 '09 at 15:20
  • Unfortunately, I didn't have the strace package installed on this server before this problem appeared...meaning when I go to install it via sudo now, I get a "permission denied"... – user20136 Sep 14 '09 at 15:38
  • what about command: "grep root /etc/passwd" – savecore Sep 17 '09 at 14:57
  • grep should give you line like this: root:x:0:0:root:/root:/bin/bash if u have '1' instead first '0' probably someone made you a ... joke, backup everything u can without root access, u may attach disk to another linux box and backup, if regardles the risk u wan to stay with that system, add 's' parameter to the kernel during boot- u'll have system in single user mode with root shell - edit /etc/passwd, chang '1' to '0' for root in passwd, reboot. – savecore Sep 17 '09 at 15:06

Your Answer

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