May
9
A Root Shell On Ubuntu : The Right Way
Filed Under Ubuntu
Just the other day we were having a discussion on using the root shell in Ubuntu. Now, remember, the root user account is disabled with no assigned password on a default Ubuntu system so administrative tasks need to be done using the sudo command. For nearly all of the administration you would need sudo will be adequate. There are occasionally those fringe cases where you might require a root shell. Below I have a few alternatives and then, if you must, the correct way of opening a root shell.
For more information please see the RootSudo page on the Ubuntu Community Wiki.
Alternatives To A Root Shell
One of the most common reasons that a user might need a root shell is due to output redirection not working as expecting while using sudo. This can be bypassed fairly easily. Let me outline an example:
sudo echo “foo” > /root/somefile
The above example will not work because the normal user does not have access to write to the root user home directory, and combining the redirection in the command we’ve lost sudo access.
An alternative that will work would look something like this:
echo "foo" | sudo tee /root/somefile
This will echo the output on the console but the tee command ('man tee‘ for more information) will also take that output and write it to the file as expected. Also note that 'tee -a' will work in the same fashion as >>, appending the data to the current file vs overwriting.
The Proper Way To A Root Shell
If you still need a root shell (perhaps you’ve come across a different scenario? perhaps you’re just lazy? perhaps you’re coming from another distribution?) let me outline the proper way to gain a root shell.
DISCLAIMER: This should be avoided if at all possible. It is not suggested to run a root shell on an Ubuntu system. Use at your own risk. See examples above, etc.
sudo -i
The command sudo -i is the equivalent to the 'su -' command. This will properly change to the root user, switch to the root user’s home directory, use his (her?) environment values, etc.
sudo -s
The command sudo -s is the equivalent to the 'su' command. This will change to the root user but will not properly use his (her?) environment values, etc.
The WRONG Way To A Root Shell
Please DO NOT use the following methods to gain root access:
sudo bash, sudo sh, sudo su -, sudo su, sudo -i -u root
If you currently do use these methods this post was written for you!
UPDATE: Based on the feedback in the comments for this post I’ll try to expand the reasoning on *why* the right way is the preferred way.
First of all we need to understand some background information. When a user creates a session there are a number of environment values that are set. To have a look at some of these try this command:
env
This will output a number of details about the current working environment. These environment values may be different for different users. Some of the values are generated by way of the .bashrc file (assuming a bash shell, of course), the .bash_profile, etc. Take a look at the .bashrc in your users home directory and compare it with the .bashrc in root’s home directory.
diff -u ~/.bashrc /root/.bashrc
You should see some differences, and this is just from one of the multiple files that are read during a proper login.
When creating a root shell by using ‘sudo bash‘ you are not incorporating the root environment properly. You are creating a shell with root privileges but the env output is still that of your user. Each user, whether unprivileged or root, should have unique environment settings to truly be that user. This will be the case for ‘sudo bash‘, ‘sudo su‘ and ‘sudo sh‘.
I post tutorials very regularly on this site. You may want to consider subscribing to the RSS feed. Or if you'd prefer these tips sent to your inbox you can use Email Subscriptions.
Related Posts
Random Posts
Comments
23 Responses to “A Root Shell On Ubuntu : The Right Way”
Leave a Reply
-
Blogroll
Subscribe to the RSS feed!
Get Ubuntu!
Obama '08
I keep hearing that “sudo bash” is bad, but i never see an explanation.
Why is “sudo bash” considered harmful?
Interesting post. I do use sudo su. An explanation as to why this should not be used will be very helpful. Thanks!
@alphager - ’sudo bash’ will no longer have any of the benefits of the sudo system. ie; auditing, granular access controls, environment inheritance, etc. See the link to the wiki for more benefits of sudo, most of which are lost using ’sudo bash’ or similar.
I get root access in a way that isn’t even listed here - I just went into recovery mode and made a password for the root account.
Personally I like it this way - for basic tasks I just use sudo, but for the more involved tasks I can use su.
Whats wrong with “sudo su -”?
Seriously– this is a nice article but it’s missing the most important part–educating the reader about what’s wrong with sudo bash!
Because that’s what I almost always use… so what am i doing wrong?
@mirada
next time, try :
$sudo passwd
What makes “the right way” right?
What makes “the wrong way” wrong?
I was hoping PolicyKit would solve the need for “sudo nautilus” or “sudo gedit”, but it didn’t. It’s such a pain to re-do work if you forget to put sudo in front…
@Vadim - check out the RootSudo link I have posted. You should be using ‘gksudo gedit’ or ‘gksudo nautilus’ instead as well.
I don’t see the differences between sudo -s (the one I use) and sudo bash.
In both I don’t get to use the root’s environment values.
To avoid a lot of garbage being sent to the console when zcatting a binary file, you can redirect to /dev/null:
zcat file.gz | sudo tee /dev/device >/dev/null
Now that more closely resembles the behavior you would expect from:
sudo zcat file.gz > /dev/device
BTW, this used to work using Gutsy. What exactly has changed in Hardy?
I see the issue with “sudo bash” but why wouldn’t “sudo su -” get the proper environment?
Hmm. “sudo su -” to do the job.
Unless there’s some sort of security issue with what I do know, I honestly can’t think of any way my life could possibly be improved by using “sudo -i” instead. Not that it would hurt either, but my fingers are well-trained to my current method.
Manuel: Correct, in neither case you get the root’s environment.
However, (if I understand this article correctly?), in the “sudo -s” case, you don’t get the environment of any particular user, while with “sudo bash” you get the environment of your normal user. The latter is considered bad. But why?
Thankyou! I’ve always used sudo su -, but the X display env var doesn’t get set. Using -i it does!!!
Hugo- I don’t get it either. I’ve never had any issue with the normal user environment…
W
Count me as another that wants to know what’s the difference between “sudo -i” and “sudo su -” Either way you get root’s env, so what difference is it? Ditto on “sudo -s” v “sudo su” Either way, no root env…
The reason why “sudo su” and “sudo su -” are considered the wrong way is that they take unnecessary detours. At least that’s my take on it.
“sudo -s” becomes root when executed, reads the password, then starts a shell.
“sudo su” becomes root when executed, reads the password, then starts su, which looks whether it needs to read the password, discovers that it is already root, says “huh?” to itself, and starts a shell.
The extra work just feels wrong to me.
Whereas “sudo -s” starts the shell mentioned in $SHELL (or /etc/passwd if $SHELL is not set), “sudo bash” always invokes bash. I wouldn’t say that makes it wrong, just different. But I can see how “sudo -s” would follow the principle of least astonishment, where the user gets their normal shell they are used to without having to remember what exactly that shell is.
Interesting… I diffed ’sudo su -’ and ’sudo -i’:
- = sudo su -
+ = sudo -i
-MAIL=/var/mail/root
-PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
+SUDO_USER=user
+SUDO_UID=1000
+USERNAME=root
+PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
+SUDO_COMMAND=/bin/bash
+SUDO_GID=1000
+DISPLAY=:0.0
+XAUTHORITY=/home/user/.Xauthority
+COLORTERM=gnome-terminal
So I guess the author is wrong - ’sudo su -’ seems to be the cleanest approach. sudo -i however allows you to start X apps, so it’s more convenient.
I did another diff:
- = sudo su -
+ = direct root login from console
-TERM=xterm
+TERM=linux
+HUSHLOGIN=FALSE
-PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
+PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
There’s also “sux” if you want the X stuff put through. “sudo sux -”
Could always add the menu entry for a root shell through System > Preferences > Main Menu. The option is under System Tools.
(assuming you use gnome)