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

Quentin Glidic sardemff7 at exherbo.org
Sun Feb 10 11:34:31 UTC 2013


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


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


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

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.

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

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.

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