How do you use sudo to run a command as the actual root user on Ubuntu? I originally thought this was the default behavior of sudo, until I ran:

myuser@localhost:~$ sudo echo `whoami`

myuser@localhost:~$ sudo -u root echo `whoami`

However, this is the type of behavior I want, but only in a single line:

myuser@localhost:~$ sudo su -
root@localhost:~# echo `whoami`
  • 11
    why echo whoami? Just say sudo whoami.. returns root – Neo Jan 31 '12 at 22:24

In fact it does run them as root. But, what's happening to you is that the back ticks are being evaluated before sudo runs, as they're needed to evaluate the command. More directly, why not just this:

sudo whoami

Your whoami in back ticks is actually evaluated in a subshell as the current user, which is why you see what you do.

  • 2
    This is wrong. sudo runs with root privileges but not as root. – Manfred Moser Jan 31 '12 at 22:41
  • @Moser, Then why does his command print "root"? – Cerin Jan 31 '12 at 22:52
  • 4
    @ManfredMoser: It runs with the UID of 0 (zero), which is exactly what people call "root". (You would have been right if sudo only extended its capabilities without actually changing the UID. But that's not what it does.) – user1686 Jan 31 '12 at 22:57
  • 1
    M. Moser might have been making a point about set-UID only changing the effective user ID of the process, requiring that the process itself then go about changing the real user ID, as indeed sudo does. But from reading xyr answer, this does not seem to have actually been the case. – JdeBP Jan 31 '12 at 23:45

The subshell (whoami) is executed first, as you, and the result (myuser) is placed into the sudo command; what sudo sees is echo myuser. Think of it as a shortcut for:

sudo echo "$tmpvar"

There seems to be some surmising going on here…

The backticks are obviously doing what others explained, expanding whoami before invoking 'sudo', and leaving the backticks off return 'root', as expected.

But it's useful to understand what is actually happening with sudo(8). So I actually looked at the man page!

"The real and effective uid and gid are set to match those of the target user…"

So it appears that the observed behaviour has nothing to do with the difference between effective and real user id.

It's also illustrative to do "sudo printenv" and compare to just "printenv," which actually surprised me a bit. It shows that [i]some[/i] exported variables are available and and others are not: it reports the invoking user's HOME, PATH, PS1, SHELL, TERM, and EDITOR, but not others like MANPATH, CVSROOT, LD_LIBRARY_PATH, or ENV. That seems a bit odd, as it could cause programs to behave differently than they do either as the original user, or as root.


sudo allows you to run any command with root privileges, but not as root user. The reason this is useful is that with this setup multiple people can have root rights yet all the logging and so on still indicates who did the changes.

This setup is better than sharing root passwords. As such it has replaced having a root users on many distributions including Ubuntu.

sudo su on the other hand makes you the root users and therefore should not really be used.

This difference also explains your observed (correct) behaviour.

  • 6
    No. What explains the behaviour is a very simple matter of how command substitution in the shell works. It's nothing at all to do with privileges. – JdeBP Jan 31 '12 at 23:49

Sudo temporarily grants who ever you are (given you are allowed to sudo in the first place) root level privileges.

To be root, you'd have to log in as root which is blocked in Ubuntu by default.

You need to be careful with this, sudo is not root. If you want to show That Fred is executing something as sudo, che3d the SUDO environment variables, SUDO_COMMAND might be the most useful.

  • Root is blocked in Ubuntu? Are you sure about that? I know it's discouraged, but I thought they just made it slightly more difficult for a novice by actually setting an obscure password using a UUID, which can be changed using the usual methods. – Marty Fried Feb 7 '12 at 1:40

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.