4 Answers
4

keeps your $HOME directory, so when you start programs, they will use your (and not root's) config files etc. Disadvantage: they can also change the ownership of your files in the $HOME directory, typical example is the .Xauthority file, but I have never experienced a problem with that.

sudo su or sudo -i

programs will use the root's home directory and its config files. This might be more intuitive, but it also means that it will not use any configuration you may have set for yourself (aliases, bash history,...).

"sudo su" is not equivalent to "sudo -i". "sudo -i" is equivalent to "sudo su -" but "sudo su -" keeps the current working directory while "sudo -i" moves you into root's home
–
Gregory PakoszFeb 22 '12 at 21:50

I would disagree with other answers when considering the cases when you want to log in as a user who do not have a shell. That is a very common case with users assigned to services.

Using "sudo su" will start the shell specified by the user. However in the case of a user assigned to server process, the shell is /usr/bin/false and the logging will fail. Instead you should enter as:

sudo -sHu <server-user>

that will log you in and cd to its home path, even if the user does not have a shell assigned

Aside from the already mentioned differences with environment variables, I find sudo su silly and wasteful because you are asking sudo to run su as root, and ask it to run a shell as root. Why ask a program to ask a program to give you a root shell, when you can just have the first program give you that shell? Does that matter in any practical sense? No, I'm just pedantic.

Because sudo -s will not change your environment variables, especially $HOME, which will stay HOME=/home/USER. If you use sudo su this will change to HOME=/root which can have negative side effects when programs you start try to access your user's home directory.