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

Jonathan Oksman jonathan.oksman at
Sat Mar 17 07:43:38 PDT 2007

On 3/16/07, Dan Nicholson <dbn.lists at> wrote:
> On 3/16/07, Jonathan Oksman <jonathan.oksman at> wrote:
> > 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 agree with you, I actually changed the default behavior of that script
as of yesterday.  After thinking about it, there are very few users that
I want to actually have group read/writable as a default.

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

Once again, I completely agree - I'd rather not do it like this if it
is preventable.  In fact my whole reason for "restoring" root's PATH
was because of su's decision to change it.

> It works differently with PAM. If you have in your su
> configuration, it will read settings from /etc/security/pam_env.conf
> and you can set the default path there.

Beautiful, I will play with that once I get to installing PAM in my
BLFS 6.2 environment.  It might not be necessary for me, though since...

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

Yeah, I've been playing with sudo for a few hours now and while the
configuration is kind of crazy, the defaults are sensible.  Setting
umask and leaving PATH alone addresses both of my concerns and leaves
the login scripts alone to their natural order.  sbin's aren't
necessary for installing packages anyways, but I did want it to factor
/usr/local which it does correctly now (as long as the user has it
in their PATH to begin with).

I'll probably start abolishing su, it's gradually seeming less reliable
to me.  I remember back before I used LFS when /etc/suauth worked... I
never did find out what happened with that.  Maybe it was a distribution
specific patch.

On a simular topic now that we've started discussing sudo, I noticed the
book tells the user to just read the sudoers man pages for configuration.
A good call since it has some bizarre syntax.  However, the default
options for sudo log authentication info into /var/sys.log.

Perhaps either the configure option --log-fac=auth or the
/etc/sudoers "Defaults syslog=auth" option should get an honorable mention
in that section to keep authentication messages in /var/auth.log.

I'm leaning towards --log-fac since discussion of sudoers is left to the
reader as an exercise.


More information about the blfs-dev mailing list