On 3/16/07, Jonathan Oksman <[EMAIL PROTECTED]> 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 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
