[Exherbo-dev] ROOTPATH, pam_env and profile.env
compnerd at compnerd.org
Sat Feb 9 22:46:00 UTC 2013
On Wed, 06 Feb 2013, Quentin Glidic wrote:
> Let’s start with the easy part.
> I’m going to drop ROOTPATH and use
> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin for everyone.
> Every Exherbo user is highly likely to be a super user, so there is no
> real point to keep her from using sbin stuff.
> To achieve that, I will add the full PATH to /etc/env.d/00basic, and
> simply drop the redefinitions in /etc/profile and other shells
> equivalent files (e.g. zprofile).
/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
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
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.
> Now that we have a clean environment, let’s use it correctly.
> Using profile.env assumes everything will launch a shell to set the
> environment up. This is wrong. DMs parse or source sometimes
> /etc/profile to get the basic env, but more rarely the user files. It
> depends on the distribution sessions scripts too. It’s messy to work
> with. Tools like weston-launch (to launch Weston from a TTY) simply
> clean the environment, then launch the compositor: no way to get
> profile.env in.
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 solution is to use PAM, which is common to all these, even the TTY
> login. pam_env module have been around for ages, but not used in the
> default configuration.
> I will push some basic change to the eclectic env module to keep the
> simple KEY=VALUE file around, without the export used in profile.env.
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.
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.
> So, here is the status after these two changes:
> — No more ROOTPATH, and a full usable PATH with all the tools you need
> — The environment is set correctly when using PAM (TTY login, DMs,
> weston-launch) with all package-specifics vars
> Now, the tricky part.
> With the pam_env usage, profile.env becomes obsolete. The full
> environment is here, for every session.
> Keeping it around makes shells a bit slower, with no benefit since the
> work is done already.
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.
> Is there any reason to keep profile.env around then? (Same question for
What about expected shell behaviour of login vs non-login shells (environment
sourcing is supposed to be different across the two).
> I would push the first two changes in a week if nobody objects in the
> meantime, and the third one in about a month.
> Quentin “Sardem FF7” Glidic
> Exherbo-dev mailing list
> Exherbo-dev at lists.exherbo.org
More information about the Exherbo-dev