I always use ‘sudo su -‘ when I need to get to a root shell. I have seen a few people before, and a new co-worker recently use ‘sudo -s’. Since I could not remember off hand the actual differences between the two, I had to check. The following will run through the actual limitations.
The big difference when using ‘-s’ are listed below
-s The -s (shell) option runs the shell specified by the SHELL environment variable if it is set or the shell as specified inpasswd(5).
Below is the typical sudo command when going to root
$ sudo su –
Now that we are root, check the current environment variables. Here we see that we are in the bash shell, which is different from the Korn (ksh) shell that the user was in. Also note, the home directory is ‘/root’, and the ‘PATH’ locations.
[root@testServ01 ~]# printenv HOSTNAME=testServ01.testDomain.com SHELL=/bin/bash TERM=xterm HISTSIZE=1000 USER=root PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin INPUTRC=/etc/inputrc PWD=/root LANG=en_US.UTF-8 SHLVL=1 HOME=/root LOGNAME=root CVS_RSH=ssh LESSOPEN=|/usr/bin/lesspipe.sh %s DISPLAY=localhost:10.0 G_BROKEN_FILENAMES=1 _=/usr/bin/printenv
When ‘sudo su -‘ was executed, we were in the testuser01 home directory (/home/testuser01). After execution, we are now in the root user home directory (/root)
[root@testServ01 ~]# pwd
/root
Now that we have seen what ‘sudo su -‘ does, lets check out ‘sudo -s’.
$ sudo -s
Time to check the current environment variables again. Main things to note here are the home directory, PATH definition, and the SUDO_* variables. This is definitely different then what was listed before.
# printenv
_=/usr/bin/printenv
DISPLAY=localhost:10.0 HISTSIZE=1000 HOME=/home/testuser01 HOSTNAME=testServ01.testDomain.com INPUTRC=/etc/inputrc LANG=en_US.UTF-8 LOGNAME=root MAIL=/var/spool/mail/testuser01 PATH=/usr/bin:/bin PWD=/home/testuser01 SHELL=/bin/ksh SUDO_COMMAND=/bin/ksh SUDO_GID=500 SUDO_UID=500 SUDO_USER=testuser01 TERM=xterm USER=root USERNAME=root
When ‘sudo -s’ was executed, we were in the testuser01 home directory (/home/testuser01). After execution, you can see that we are still in the same directory.
# pwd
/home/testact
Since the ‘PATH’ variable was passed from the testuers01 shell to the sudo environment, the administrative tools directories (/sbin, /usr/sbin) are not listed. This is not a huge issue, just more of a hassle if there were not passed from the user account.
Since this was the case for the test, I tried to issue ‘iptables’ without the absolute path. Per below, it failed.
# iptables -L /bin/ksh: iptables: not found [No such file or directory]
Since I do actually have root level access, when I issue the command with the absolute path it works fine
# /sbin/iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination RH-Firewall-1-INPUT all -- anywhere anywhere Chain FORWARD (policy ACCEPT) target prot opt source destination RH-Firewall-1-INPUT all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination
To conclude ‘sudo -s':
Notes: So to be safe, I will still use ‘sudo su -‘ when needing root level access. Seems that the ‘sudo -s’ option would be a little more safe for some users. Mainly due to the sbin locations not being in the ‘PATH’. This would make the user execute most administrative commands using the full path to the executable, unless sbin(s) were exported.
The big difference when using ‘-s’ are listed below
<li>This option reads the environment or password file for the shell to be executed. Does not execute root shell!
<li>All environment variables are passed over from the current account to the root account
Per the Linux man page for sudo
<pre>-s The -s (shell) option runs the shell specified by the SHELL environment variable if it is set or the shell as specified in
passwd(5).</pre>
Below is the typical sudo command when going to root
<pre>$ sudo su -</pre>
Now that we are root, check the current environment variables. Here we see that we are in the bash shell, which is different from the Korn (ksh) shell that the user was in. Also note, the home directory is ‘/root’, and the ‘PATH’ locations.
<pre>[root@testServ01 ~]# printenv
HOSTNAME=testServ01.testDomain.com
SHELL=/bin/bash
TERM=xterm
HISTSIZE=1000
USER=root
PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
INPUTRC=/etc/inputrc
PWD=/root
LANG=en_US.UTF-8
SHLVL=1
HOME=/root
LOGNAME=root
CVS_RSH=ssh
LESSOPEN=|/usr/bin/lesspipe.sh %s
DISPLAY=localhost:10.0
G_BROKEN_FILENAMES=1
_=/usr/bin/printenv</pre>
When ‘sudo su -‘ was executed, we were in the testuser01 home directory (/home/testuser01). After execution, we are now in the root user home directory (/root)
<pre>[root@testServ01 ~]# pwd
/root</pre>
Now that we have seen what ‘sudo su -‘ does, lets check out ‘sudo -s’.
<pre>$ sudo -s</pre>
Time to check the current environment variables again. Main things to note here are the home directory, PATH definition, and the SUDO_* variables. This is definitely different then what was listed before.
<pre># printenv
_=/usr/bin/printenv
DISPLAY=localhost:10.0
HISTSIZE=1000
HOME=/home/testuser01
HOSTNAME=testServ01.testDomain.com
INPUTRC=/etc/inputrc
LANG=en_US.UTF-8
LOGNAME=root
MAIL=/var/spool/mail/testuser01
PATH=/usr/bin:/bin
PWD=/home/testuser01
SHELL=/bin/ksh
SUDO_COMMAND=/bin/ksh
SUDO_GID=500
SUDO_UID=500
SUDO_USER=testuser01
TERM=xterm
USER=root
USERNAME=root</pre>
When ‘sudo -s’ was executed, we were in the testuser01 home directory (/home/testuser01). After execution, you can see that we are still in the same directory.
<pre># pwd
/home/testact</pre>
Since the ‘PATH’ variable was passed from the testuers01 shell to the sudo environment, the administrative tools directories (/sbin, /usr/sbin) are not listed. This is not a huge issue, just more of a hassle if there were not passed from the user account.
Since this was the case for the test, I tried to issue ‘iptables’ without the absolute path. Per below, it failed.
<pre># iptables -L
/bin/ksh: iptables: not found [No such file or directory]</pre>
Since I do actually have root level access, when I issue the command with the absolute path it works fine
<pre># /sbin/iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all — anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all — anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination</pre>
To conclude ‘sudo -s':
<li>does NOT change the shell
<li>’PATH’ does not change since root shell is not executed
<li>carries over all environment variables from the non-privileged user
Notes: So to be safe, I will still use ‘sudo su -‘ when needing root level access. Seems that the ‘sudo -s’ option would be a little more safe for some users. Mainly due to the sbin locations not being in the ‘PATH’. This would make the user execute most administrative commands using the full path to the executable, unless sbin(s) were exported.
Posted in Linux, Security