Programs use old home after "su"
 

I'm upgrading from an ancient SUSE installation where I found it useful to switch users with "su" and then run applications like mozilla, emacs, etc. Once I arranged the X authentication to allow this, it worked fine.

Now I have installed a debian derived distribution (Mepis 2004.04) with the 2.6.7 kernel and I find that after issuing an "su", firefox, mozilla, and emacs start up with the config info from the original user's home, not the configuration corresponding to the current uid.

The old "su" program was part of GNU sh-utils 2.0. The new "su" doesn't give a version number of any other identifying information other than its author, Julianne Frances Haugh. The new program also uses pam. It appears to be completely different than the old "su".

How do programs even know the home directory of the original user? Is there a way I can restore the old behavior I was accustomed to, perhaps by modifying the pam configuration fils?

Perhaps just a su - or even su - user1 will fix your problem. Majority of the time, when issuing a su, its still going to use the old users path. With the - or - [user], it uses the new users full path, etc.

Well, 'su -' resets the environment which means it clears things like DISPLAY and WINDOWID, which is troublesome. I might be able to kludge something in the .login files to make this work. But I wasn't using 'su -' before with the old su and it was working. I am also curious to understand the mechanism whereby applications start up with startup info that is not from the home directory corresponding to the current uid.

Maybe the only way around this would be for you to include the users actual home directory is updated. After su'ing, you can envoke something like:

export HOME=/home/newuser

Which should use the new users home directory, thus using their configs, etc.

After "su", the HOME variable is set to the home of the new uid. But applications still use the home of the OLD uid when they start up.

I hunted through the environment for traces of the old user and found something. There is a variable LOGNAME which has the name of the old user. So setting that to the new user gives the desired behavior. It would appear that doing the equivalent of
export LOGNAME=$USER
would do the trick. This is, however, still in the category of kludge in shell's init files. Is there some reason why the behavior of su has changed in this fashion? Is there a way to get su to reset LOGNAME?

You should be able to add

export LOGNAME=$USER

to either ~/.bash_profile or ~/.bashrc . That is what they are there for. ;)

Of course. I was thinking I could add it to the system wide file in /etc. Bit will there be any strange side effects? Could it perhaps affect suid processes? Maybe it would make them unable to determine the calling user, for example? Would it be undesirable do have LOGNAME=root?

Well, myself I would just try it. My understanding is that su username only sources ~/.bash_profile and ~/.bashrc for the user, while su - username sources the files in /etc first, then the users files. You don't want to fully reload the environment, Just alter the su environment, so I'd try doctoring the ~/ bash files. Back them up first though. ;)

Actually bash reads /etc/bash.bashrc and ~/.bashrc when started as a non-login shell. This is how it would be started with a simple su. With 'su -' you get a login shell. For a login shell bash first reads /etc/profile and then it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile.

I suspect that if there are any undesirable effects of setting LOGNAME=$USER, they are likely to be somewhat subtle, and unlikely to surface soon. That's why I was asking if anybody knew of any reason not to do this.

Hmm... well that must be distro dependant, as that is not how it works in LFS, my distro. There is no /etc/bash.bashrc. Learn something new all the time. :) Regards.

Kind of a weird thing to have vary from distro to distro. I guess it could depend on the version of bash they included. (I have 3.00.)

Could be, I'm using bash 2.05b . Also might have to do with compile time configure options. I know that it is possible to change config file name and location that way with some packages.