[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: L A Walsh
Subject: Re: Bash should reset OLDPWD upon login, *only*.
Date: Tue, 03 Oct 2017 15:01:54 -0700
User-agent: Thunderbird

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

# 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]