Section: The Bash Shell Startup Files - PATH=/your/head/asplode

Dan Nicholson 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
> PATH=/sbin:/bin:/usr/sbin:/usr/bin.

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

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.

http://www.linuxfromscratch.org/blfs/view/svn/postlfs/shadow.html

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

--
Dan



More information about the blfs-dev mailing list