[Exherbo-dev] ROOTPATH, pam_env and profile.env

Saleem Abdulrasool compnerd at compnerd.org
Tue Feb 12 07:41:14 UTC 2013

On Sun, 10 Feb 2013, Quentin Glidic wrote:

> On 09/02/2013 23:46, Saleem Abdulrasool wrote:
> > /sbin is meant for system binaries that are needed for system 
> > administration only.  Any non-critical (i.e. not required for system 
> > boot or recovery) system administration binaries should go to 
> > /usr/sbin.
> > 
> > If you feel like there are binaries which reside in /sbin or 
> > /usr/sbin currently and should be moved into /bin or /usr/bin please 
> > start a thread on that separately.
> >
> > What you are proposing strictly violates the FHS.  It explicitly 
> > states that /sbin and /usr/sbin are to be included in PATH for the 
> > root user *only*.  If you wish to ignore this recommendation from
> > the FHS, please state this clearly, and ideally, provide some 
> > justification.  Effectively, what you are proposing would merge /bin 
> > and /sbin, /usr/bin and /usr/sbin.  It seems that the more efficient
> >  way to do this would be to just do that -- merge them and delete 
> > /sbin and /usr/sbin.
> I do.
> > While "every exherbo user is highly likely to be a super user" is 
> > very much an expectation, I don't think that warrants merging system 
> > administration binaries into the usual day-to-day environment. System
> > administration is not the primary use of the system in most cases.
> I think arguments a) to g) (e) being for zsh because we already have
> ROOTPATH in PATH for our default zprofile) of this email (please don’t
> troll the author…) are pretty relevant:
> https://lists.fedoraproject.org/pipermail/devel/2011-October/158845.html

The server seems to be inaccessible, at least for the moment.

> > Parsing random scripts seems extremely fragile to me.  Why not fix 
> > the DM to properly handle environment setup instead?  This seems
> > like a much cleaner solution to me.  The DM is less likely to break
> > in the future if the syntax changes while being able to take
> > advantage of improvements in newer versions of the interpreter.
> DM just run a session script (sh most of the time) which sources
> ~/.profile or even ~/.xprofile. These scripts are often (always?)
> distro-specific.

If they are able to simply source the scripts, it implies that they have
launched a shell, which should setup the environment as appropriate.  I dont see
why you brought up the point of DM interactions at all then.

> > PAM is not an absolute requirement for a working system and not all 
> > tools are PAM enabled (e.g. chroot and a number of tools from 
> > coreutils).  With your proposal, you have introduced a mandatory 
> > usage of PAM for everyone, and potentially on programs which do not 
> > currently support PAM.
> PAM is enabled for login, su, XDM, GDM, LightDM, SLiM and LXDM. OpenSSH,
> Dropbear and sudo have a pam option (some others too, but they are not
> involved here). These options could be killed, unless there is a
> specific use case where one would like to avoid PAM (I don’t know all
> SSH usages), because PAM is in system (trough util-linux and shadow at
> least).
> Every login entry point are PAM-enabled. And we can always keep
> profile.env for corner cases.

As far as GDM, yes, PAM is not "enabled" for GDM, it is a strict requirement for
it.  That said, I use system configurations with and without PAM though.  There
is no reason to drop those options.

> chroot is a corner case, because it does not change the environment nor
> it launches a login shell. Since we do not source profile.env in our
> default bashrc, the environment is not modified at all when chrooting
> Exherbo, and the install guide asks to source /etc/profile. We can just
> change that to profile.env.

I use chroot with a login shell quite often.  So, yes, it does change the
environment, and it does launch a login shell.

> > One issue with the use of pam_env for this purpose is that you now 
> > need to restart your session to get an environment change as 
> > restarting your shell is no longer sufficient to get the changes to 
> > /etc/environment.
> In case of login shells, you already have to restart the whole session.

You can manually launch a login shell without creating a new session.

> In case of non-login interactive shells, the default bashrc does not
> source the profile.env, the default zshrc does. Again, we can keep
> profile.env around for these cases (the user can either add the source
> in her ~/.bashrc or source manually after an update).

If the issue is really that /etc/bashrc does not source /etc/profile.env, why
not just change that?

> In case of non-shells (X sessions), you still have to restart the
> session. An example is when you install a new Firefox plugin, it may
> need to update MOZ_PLUGIN_PATH variable. gnome-session and others might
> provide an interface to update the environment at runtime but that’s
> another debate.

The point is that you do not currently need to restart the session, you can
simply spawn a new shell.

> Also, to update the existing shell environment variables, sourcing
> /etc/environment is enough.
> > Evaluating a few variables is not that expensive on modern machines. 
> > We can still cleanup the environment setup and optimise the variable 
> > setting to avoid re-calculating values if that is an issue.
> Not an issue, just a little bonus. But one can want Exherbo on some slow
> hardware (using pbins maybe, and cross is going to make that really easier).
> > What about expected shell behaviour of login vs non-login shells 
> > (environment sourcing is supposed to be different across the two).
> Yes, non-login shells are not supposed to modify the environment, unless
> explicit user action (tweak the ~/.bashrc or execute commands).
> -- 
> Quentin “Sardem FF7” Glidic

More information about the Exherbo-dev mailing list