Re: Bash should reset OLDPWD upon login, *only*.

[L A Walsh]

Mikulas Patocka wrote:
> The problem is not intentional sabotage of /etc/profile (there are many 
> other ways how to sabotage /etc/profile without $OLDPWD - and protecting 
> against all of them is futile).
>   
---
   Ah, because you can't protect against everything, you leave your system
open with no passwords on the logins?  What's your system name again? :-)


> The problem is that $OLDPWD causes unintended activations of the 
> automounter and unintended delays. For example
> /root# cd /some/automounted/directory
> /some/automounted/directory# cd ~
> /root# /etc/init.d/mail-daemon start
>   
----
   root should be responsible not to start daemons from an unsafe
environment.  I.e. root must be responsible not to inflict damage in
their environment before starting a daemon.  In this case, you
could simply have used:

>  OLDPWD="" /etc/init.d/mail-daemon start

   I agree it is a pain.  But that doesn't mean the shell should try to
protect you from something that you have control over.  I.e. root could
do:

# mount --bind / /tmp
# rm -fr /tmp /*

You'd hurt yourself 2 ways with that mess. 

> - now, the mail daemon inherits OLDPWD=/some/automounted/directory and 
> every incoming email will poke this directory and activate the automounter 
> and cause delay.
>   
---
   Now that you know about this, I've noted all of my init.d scripts
call something like "rc.config".  I could put
OLDPWD="" in them so it isn't propagated to children.

   If it is really a problem, you should contact your distro folks to fix
it. 

   I'm not saying it isn't a problem -- just that bash isn't the right 
place
to fix it because it could break someplace that is *relying* on OLDPWD
keeping its value. 

> Note, that when the admin starts the mail daemon, he may already forget 
> what directory he was in before (if he keeps the console open for many 
> days and he did some work on the automounted directory the day before), so 
> he may not even be aware of the problem.
>   
----
   Right -- and they may have forgotten they mounted "/" on "/tmp" to test
something.  Later, when they see a bunch of junk in "/tmp" they
might "clean" it.  Forgetful admins need to protect themselves from
mistakes (not that I'd have any experience with such problems... ;^?  ).

   In this case, the service start script should routinely "clean" its
environment.  Most service scripts reset PATH -- and similarly, if
it is a likely problem, most should probably reset OLDPWD.