[Exherbo-dev] ROOTPATH, pam_env and profile.env
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:
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?)
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
> 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