I was wondering what the difference is between sudo -i and sudo su?
Difference between sudo -i and sudo su
sudo;command;su
Based on the descriptions from the man pages for su and sudo I would assume the following things.Since sudo -iu <user> means a login shell this would be equivalent to an su - <user> or su -l <user>. An su without any arguments changes your effective user ID but you're still using your original <user> environment and a who am i will report you're still <user>.excerpt sudo man page-i [command]        The -i (simulate initial login) option runs the shell specified in        the passwd(5) entry of the target user as a login shell.  This means        that login-specific resource files such as .profile or .login will         be read by the shell.  If a command is specified, it is passed to         the shell for execution.  Otherwise, an interactive shell is         executed.  sudo attempts to change to that user's home directory         before running the shell.  It also initializes the environment,         leaving DISPLAY and TERM unchanged, setting HOME, MAIL, SHELL,         USER, LOGNAME, and PATH, as well as the contents of         /etc/environment on Linux and AIX systems.  All other environment         variables are removed.ExampleI have a user account, saml with a UID of 500.$ egrep Uid|Gid /proc/$$/task/$$/statusUid:    500 500 500 500Gid:    501 501 501 501In the above output, the 1st column is my real UID (uid) and the 2nd is my effective UID (euid).Becoming root via (su)$ suNow I'm root, but I still maintain my environment and my real UID is still 500. Notice that my euid is now 0 (root).$ egrep Uid|Gid /proc/$(pgrep su -n)/task/$(pgrep su -n)/statusUid:    500 0   0   0Gid:    501 501 501 501However my environment is still saml's. Here's one of he environment variables, $LOGNAME.$ env | grep LOGNAMELOGNAME=samlBecoming root via (su -) or (sudo -i)$ su -With an su - or sudo -i not only do I change my effective UID to a new user, but I also source their files as if it was a login, and my environment now becomes identical as if I were them directly logging in.$ egrep Uid|Gid /proc/$(pgrep su -n)/task/$(pgrep su -n)/statusUid:    500 0   0   0Gid:    501 501 501 501However my environment is now root's. Same variable, $LOGNAME, now it's set with root.$ env | grep LOGNAMELOGNAME=rootSo then what's the difference?Well let's try the above with sudo -i and find out.$ sudo -iNow let's look at the same info:$ egrep Uid|Gid /proc/$(pgrep su -n)/task/$(pgrep su -n)/statusUid:    0   0   0   0Gid:    501 501 501 501Well one major thing is my effective ID and real ID are both 0 (root) with this approach. The environment variable $LOGNAME is as if we logged in as root.$ env | grep LOGNAMELOGNAME=rootComparing environmentsIf we count the number of lines in say the 3 methods, perhaps there is some additional info to be had. $ env > /tmp/<method used to become root>We are left with these 3 files:-rw-r--r--  1 root root   1999 Nov  2 06:43 sudo_root.txt-rw-r--r--  1 root root   1970 Nov  2 06:44 sudash_root.txt-rw-r--r--  1 root root   4859 Nov  2 06:44 su_root.txtAlready we can see that something is up with just a plain su. The env. is over 2x the size of the others.Number of lines in each:$ wc -l su*  28 sudash_root.txt  32 sudo_root.txt  92 su_root.txtThere's really no need to look further at the su_root.txt file. This file contains a much of user's environment that ran the su command. So let's look at the other 2 files.They're virtually identical except for a few cosmetic variables, such as $LANG being slightly different. The one smoking gun in the list is the $PATH.sudo PATH=/usr/lib64/ccache:/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/brlcad/bin:/root/binsu -PATH=/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/brlcad/bin:/root/binAs you can see sudo -i gives us some additional protection by stripping out suspicious paths, but it also keeps our $DISPLAY and $TERM intact in case we were displaying a GUI to  different location.Take aways?So the big take away is that the method used to become root sudo -i is advantages over the others because you use your own password to do so, protecting root's password from needing to be given out.There is logging when you became root, vs. mysteriously some one becoming root via su or su -.sudo -i gives you a better user experience over either su's because it protects your $DISPLAY and $TERM.sudo -i provides some protection to the system when user's become root, by limiting the environment which they are given.What about sudo su, you didn't even discuss it?I intentionally avoided bringing that into the discussion even though the OP asked about it because doing so would only of confused the issue, IMO. When you run sudo su the sudo command masks the effects of the su and so much of the environment that you'd get from a regular su is lost. Sudo is doing its job and providing a limited and protected environment regardless of whether it's sudo su or sudo -i.ExampleHere's the result of the sudo su environment being dumped:ls -l /tmp/sudosu_root.txt-rw-r--r-- 1 root root 1933 Nov  2 14:48 /tmp/sudosu_root.txtAnd the number of lines:$ wc -l /tmp/sudosu_root.txt 31 /tmp/sudosu_root.txtThese are the only variables that differ between a sudo su - and a sudo -i:$ sdiff /tmp/sudosu_root.txt /tmp/sudo_root.txt  | grep ' |'USERNAME=saml                             | USERNAME=rootPATH=/usr/lib64/ccache:/sbin:/bin:/usr/sbin:/usr/bin:/usr/brl | PATH=/usr/lib64/ccache:/usr/local/sbin:/sbin:/bin:/usr/sbin:/MAIL=/var/spool/mail/saml                 | MAIL=/var/spool/mail/rootPWD=/home/saml/tst                        | PWD=/rootSUDO_COMMAND=/bin/su                      | SUDO_COMMAND=/bin/bashXAUTHORITY=/root/.xauthYFtlL3             | XAUTHORITY=/var/run/gdm/auth-for-saml-iZePuv/databSo as you can see there really isn't much of a difference between them. Slightly different $PATH, the $SUDO_COMMAND, and the $MAIL and $USERNAME are the only differences.ReferencesReal and Effective IDs