environment using su - vs "ssh user@machine" as a user on lucid

Question

I'm trying to debug a shell environment issue on a machine running lucid.

Both root & user have /bin/bash as their shell in /etc/passwd When I use "sudo su - user", my PATH includes the following directory: /usr/local/rvm/rubies/ruby-1.9.3-p194/bin/ruby when I "ssh user@machine" it has: /usr/local/rvm/rubies/ruby-1.9.2-p290/bin/ruby

Now, there are probably a number of ruby/rvm specific answers here -- that's not what I'm looking for, what I'm trying to understand is the general problem of where to look to find whatever it is that is setting the path. I know that /etc/profile gets executed, but it is being executed in both cases so I'm not sure what the issue is -- are there some other files that also get loaded on login -- in 1 case but not the other? / anything else that is being loaded that could be setting the PATH?

So it appears that something is happening before /etc/profile is loaded. I echo'd the environment on the first line of /etc/profile, and in the ssh case, the path already included a reference to /usr/local/rvm/rubies/ruby-1.9.2-p290/bin -- in the sudo su - case it did not. It appears that /etc/environment is used in the ssh case, but not the sudo su - case...

One other thing I found recently that is also relevant, from: What's the difference between "su" with and without hyphen?

the /etc/login.defs file gets used when doing su, and the /etc/environment PATH setting is overwritten by the ENV_PATH or ENV_SUPATH in there...

one clarification /etc/profile is used for login shells, but not non-login shells -- so, e.g. sudo env does not show variables that are set in /etc/profile only

while logging into an account will not show up variables that are set in /etc/environment only

Answer 1

This is probably due to the difference between login and interactive shells. See here for a nice summary.

The first file the system reads to set variables is /etc/environment. After that, which files are read depends on the way that bash has been invoked. When you ssh user@machine, you start a login shell but when you su username, you start an interactive, non-login shell. Bash will read its initialization settings from different files in each case. The following is from the bash man page (emphasis mine):

When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. The --noprofile option may be used when the shell is started to inhibit this behavior.

When an interactive shell that is not a login shell is started, bash reads and executes commands from /etc/bash.bashrc and ~/.bashrc, if these files exist. This may be inhibited by using the --norc option. The --rcfile file option will force bash to read and execute commands from file instead of /etc/bash.bashrc and ~/.bashrc.

So, bash reads different start up files depending on its invocation. Have a look at the contents of these files in your machine, you will probably find $PATH is being defined in different ways.

That said, as @mpy correctly pointed out in the comments, sudo su - user should start a login shell. Are you sure you are using sudo su - and not simple sudo su or just su? The - should start a login shell which should read exactly the same start up files as ssh user.