The real diff -- To "su -" or to "su"/

English Applications
1

After a number of recommendations over time to “su -” instead of “su” to an elevated console,
I took a few moments to take a look at this, wondering if others see anything else I’m not covering…

Note that in this case, we are <not> talking about using “su -” to switch to another User(and is different than sudo which grants specified special permissions for a single command only), eg

su - Jane_Doe

We are only considering the use of su and su - for the purposes of persistently elevating permissions to the Super User role by not specifying a User account.

Literature including the MAN pages suggests there are differences in environmentals and paths, that “su -” is the equivalent of logging in to a new session as root, whereas “su” continues to use the ordinary User’s environmentals including home directory, path, etc.

I have found that at least on openSUSE, for the most part that’s false…
There are only two minor differences…

  • The cursor’s starting point. When you “su” the cursor remains where you executed the command. When you “su -” the cursor starts in the User root’s home directory.
  • In each case you can execute “printenv” to list all environmental variables that aren’t exported. When I did this, only a few XDG configurations and settings were located in the ordinary User’s home directory which can be called almost insignificant… Does it matter where settings and configurations are stored as long as they are accessible? How important is it that a GUI setting might be shared between root and the ordinary User?
printenv

Aside from those two items,
Everything else appears to be identical…
Same home directory
Same permissions to access resources on the system.
Same $PATH, in fact all other non-XDG variables appear to be identical.

So,
Bottom line is that should you decide to “su” instead of "su - " the only significant thing to remember is that your cursor is still wherever it happens to be and if you want to be in root’s home directory, you would have to cd as follows

cd ~/

But,
If you’re looking for any kind of differences in security, use and behavior, there aren’t any.
Again, reminding that we are not talking about switching to a specified User account other than root which has different consequences.

Am I missing something?
TSU

2

I’m not sure, because I have not tested every detail.

In my case, it makes very little difference. That’s because I modify shell startup scripts to suit my needs. However, if I use “su -”, then the environment variable “$SSH_AUTH_SOCK” is not passed through. And since that’s often important for me, I prefer to use plain “su” (without the “-”).

3 
henk@boven:~> echo $PATH
/home/henk/bin:/usr/local/bin:/usr/bin:/bin:/usr/lib/mit/sbin
henk@boven:~> su
Password: 
boven:/home/henk # echo $PATH
/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
boven:/home/henk # exit
exit
henk@boven:~> su -
Password: 
boven:~ # echo $PATH
/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/lib/mit/sbin
boven:~ #

Not much time yet to check aliases.

But it is clear to me that root can execute programs with the same name from another directory then intended when not being sure aboutyou in fact did and thus have a PATH… Severe security impact.

IIRC there were some changes made to su lately. Specialy to take the noob by the hand. In any case, my advice would be to follow this from the man page:

For backward compatibility, su defaults to not change the current directory and to only set the environment variables HOME and SHELL (plus USER and LOGNAME if the target user is not root). It is recommended to always use the --login option (instead of its shortcut -) to avoid side effects caused by mixing environments.

4

su - puts you in a pure root environment. Where as su is a hybrid environment with the user plus root things mixed. In most case this works fine There may be some special case where you must become fully root without any user stuff tagging along. It never hurts to be pure root when doing system stuff so I think this is where the recommendation to use su - comes from. I don’t remember every having a problem with just su though

5

Already discussed in further detail above :wink:

6

Well yea. I was trying to boil down the tech speak and adding my own observations.

7

Practically lifted directly from authoritative sources.
But,
My point is what does that really mean? Is there really any real difference between “logging in” as root or simply changing to root? And more importantly once we understand what it really means, is it really true on openSUSE?

Is why I offer “printenv” as possibly the most useful way to directly compare each to really understand the differences.

IMO what has been posted…
The $SSH_AUTH_SOCK variable looks like an interesting variable, my guess is likely directly related to a special ssh implementation. It doesn’t show up in printenv so is I’m guessing is in a profile somewhere, either bashrc or /etc/profile.local or /etc/profile.d/… In other words, not part of a default openSUSE.

Henk’s path difference contains only one significant which I again suspect is related to an installed application

/usr/lib/mit/sbin

Other than those which may or may not be important to someone, everything else is identical between su - and su… There are no significant paths or locations that are retained from the original User account that might cause unintentional use and access to applications and files.

TSU

8

What I showed is three differnt PATH. In former times there were only two, the first and the last. The middle one (now presented after a mere su) is put there not long ago, apparently by a developer that was triggered by the lack of knowledge about how this works and how dangerous it is to have a mere user’s PATH when using the shell as root. The situation now is that a mere su creates a minimal PATH that is safe to be used by root.

It is however not root’s PATH as defined by root by using defaults and additions in e.g. his .profile. That might be a bit frustrating to root, but it is possibly not dangerous. Thus when this altered su is used (I tried to find back the release note or similar that I have seen about this, but failed), it is still better to use su -, because then root has what he will expect.

In the old situation, following a su, the PATH would be the first one (of the original user). It will depend how the original user has adapted his PATH to his needs, but as I posted it, you see the item /home/henk/bin as the first one. That would mean that when there is an executable there that has the same file name as a program that root calls, the wrong program will be started. Is that something you want to risk as root?

I thought that the danger in having a PATH that is not what you expect is clear enough for people that have used Linux for some time. This was already basic drill in Unix system manager courses 40 years ago.

And as it is still better to use su - (even if the most obvious security risks are blocked now), I will carry on to propagate it’s use to any newbee that posts here in the forums doing otherwise. A case of teaching best practices.

9

Hi
I concure, there are just too many thing that can come back to bite you :wink: It can also be dependent on the desktop environment, shell in use, with X without X (or Wayland and other compositors).

One would have to test all permutations to really be sure… far easier to use su - than have to test…

10

It’s the variable used when you run “ssh-agent”.

If I add a public key for authentication, I sometimes want to share that with root – for example, to synchronize data (with “rsync”) across several computers.