[Nottingham] TMPDIR weirdness with X logins

[Robert Davies]

On Thursday 11 Sep 2003 09:08, Robert Postill wrote:
> This is one of those peculiarities that sometimes come along almost with
> the express job of making you look stupid :).  Basically it's a question
> of login shell or not login shell.  When you login to a console, you're
> in a login shell and therefore get the bash_profile settings.  When
> you're using a window manager (and it should be true for all window
> managers) and you kick off konsole or xterm or whatever, that's a
> subshell.  The login shell is designed to be run once, subshells many
> times per session with the machine.  For example your login shell may
> contain a diary/alert daemon, that gets run once and stays resident for
> your session.  You wouldn't want that run every time you kicked off an
> xterm session, you'd just be plundering the machines resources. So you
> get a subshell.
>
> Clear as mud now? :)

I know the bash_profile is getting run once (remember original reference to 
debug log), even though login is via kdm.

Because of the difference generally ENVIRONMENT should be set in .profile / 
.login, and not .bashrc / .cshrc files, so programs can bequeath 
modifications to sub-processes where needed.  There were options on DEC  
Ultrix and Sun/BrokenWindows to select login shell for each terminal window, 
though this is wrong for other reasons (where a user really wants something 
run only on initial login and logout eg) find jobs clearing up files).

What's happening, I think is that xterm and other emulators, have black 
listing of some environmentals.  These programs need suid/sgid privileges to 
write to utmp & wtmp.  It's right to alter the environment when you have 
privileges to avoid security problems eg) LD_PRELOAD etc.  It would be though 
a lot more right, for these GUI programs starting shells for users, to 
restore the original settings, plus their essential modifications eg) 
TERM=xterm, after they have permanently revoked their suid/sgid-ness, in the 
child fork that's about to exec the non-login shell.

Actually bash only runs .bashrc for interactive processes, which avoids the 
csh problem where shell scripts have forgetten -f, and could have operation 
interfered with by environment assignments in .cshrc (it's traditional to 
test if shell is interactive there to avoid issues).  So that mitigates the 
problem, though if I start a sub-shell like this :

env TMPDIR=/var/tmp PATH=/bin:/usr/bin \
LD_LIBRARY_PATH=/opt/broken_commercial_pkg/lib bash

I really do not expect or want, LD_*, PATH and TMPDIR to get reset anyway, by 
.bashrc.  Sometimes it's nice for a program system to just setup necessary 
environment, when you need to use it and return you to an interactive shell, 
rather than force, you to carry it's baggage set per-user in every single 
shell they ever start.  Without that you can get conflict problems, where 3rd 
party packages have command name clashes.

I thought someone on the list, might happen to have been bitten by this stuff 
and know, or have a reference on the web to some info, which explains what 
get's modged, by what and why.

Rob