Section: The Bash Shell Startup Files - PATH=/your/head/asplode
dbn.lists at gmail.com
Fri Mar 16 11:46:32 PDT 2007
On 3/16/07, Jonathan Oksman <jonathan.oksman at gmail.com> wrote:
> When I'm installing packages, I tend to use su constantly so that I
> can switch in and out of root access to the filesystem. I'm sure lots
> of you do this. Others among you, notably the jhalfs developers,
> might make more use of sudo. I don't use sudo so I don't know how
> this affects it.
> In BLFS, there is no mention of /etc/login.defs. On a default lfs
> system, login.defs provides a basic PATH for users and root. When su
> is used, it draws your PATH from this file, completely avoiding
> /etc/profile.d/extrapaths.sh. Of course, this isn't the case when you
> use 'su -', since it then parses the profile of the user, although
> this is not the way people tend to call su when installing packages -
> it's not ideal to have to cd back to where you were.
> With that said, what is the problem? By default, /usr/local is
> completely ignored. This is because it is only configured in
> /etc/profile.d/extrapaths.sh, and since su is gathering it's PATH
> information from /etc/login.defs it gets the standard default of
This is actually because of shadow's su and there's not much we can do
about it. It always drops PATH and sets it to /bin:/usr/bin unless set
with ENV_PATH or ENV_SUPATH in /etc/login.defs. Coreutils' su doesn't
have this behavior, but also doesn't support PAM. Sudo also doesn't do
this, so you may want to look into that.
> The same semantics caused a simular bug with umask. My user
> (jonathan, group jonathan) got the default umask of 002 because of his
> uid being equal to gid. After compiling gpm and su-ing, I installed
> gpm user and group read-writable as root:root. Why? Because umask
> settings are controlled through /etc/profile, and su ignores it.
I'm not a huge fan of that default umask, but I suggest you set a sane
default umask for whatever user is doing the building. I actually
expect that umask gets set to 022 (the default) after you su. But some
packages aren't smart about how they create files for installation and
don't set the permissions.
I would bet that gpm's Makefile simply copies the created files to the
install location. Most autotooled packages use install and specify
-m<mode> for the installed files.
> The first fix I want to suggest breaks standard convention. The only
> way I see this consistantly working without running scripts multiple
> times would be to set PATH with /etc/bashrc instead of /etc/profile,
> and remove the settings from /etc/login.defs all together. This would
> provide root, no matter how you logged in, with the intended default
I don't really agree with setting PATH from a non-login shell, but
you've certainly highlighted the spot where this convention breaks.
> The other fix method would be to set the PATH in /etc/login.defs as
> well, but I personally hate having multiple definitions throughout a
> system for the same thing - it's just harder to maintain.
Yeah, that sucks, but I think that's how it is using shadow's su.
> Plus, there
> might be a problem with this method if you use PAM. On my BLFS-6.1
> system the PATH settings in login.defs are completely ignored when I
> use PAM, though that may be my specific configuration as I'm no longer
> using the defaults from the book. I have yet to install PAM on
> BLFS-6.2 so I could be wrong, but currently I consider this method
> with PAM unreliable.
It works differently with PAM. If you have pam_env.so in your su
configuration, it will read settings from /etc/security/pam_env.conf
and you can set the default path there.
> I don't like the fixes that I'm suggesting, but I also don't like this
> behavior, and I personally consider this to be a bug. I also don't
> see any other ways to fix it. Any thoughts?
I agree that not maintaining PATH sucks. I'd look at sudo for the
quick fix solution. Anything else short of patching shadow's su will
have undesired behavior in a different way.
More information about the blfs-dev