Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/one-true-path
Created: 2005-11-01 by TollefFogHeen
Packages affected: bash, zsh, (and any other shells shipping a profile file setting $PATH) gdm, kdm, pam
Currently, there are multiple places a user needs to change if he wants to change the $PATH for the system. This is problematic for both a system administrator as well as for Ubuntu and derivative distributions who want to change the path. There should be a single place to change the $PATH.
Having to change the $PATH in multiple places makes it harder if one wants to change the default search path. It also means it is easy to miss one or more of them when changing the paths.
- Ubuntu wants to remove /usr/games from the default $PATH.
- Colin has a ~/bin which he wants to add to his default $PATH.
Since all users will access the system through PAM it makes sense to use pam_env.so. It has been verified that at least ssh and gdm do the right thing if PATH is added to /etc/environment
Some users might want to change the system default path, this should be done by editing ~/.pam_environment. This file is not used by pam_env (yet), but TollefFogHeen has a patch for this. This is ok security-wise, since we are only reading the per-user file in the session setup at which point we are authenticated (so no problems with accidential information disclosure) and should already have setuid(2)-ed to the relevant user.
Listed in order of appearance.
- Add patch for looking at ~/.pam_environment to pam
- Change pam to add default PATH to /etc/environment on upgrades from the breezy version unless it's already there.
- Disable override of PATH in any other scripts, such as /etc/profile. /etc/profile is not a conffile, so base-files will need to be changed to upgrade the version on upgrades from the breezy version or before (if it's unchanged).
Does it have to be .pam_environment instead of just .environment? I don't think the pam_ prefix conveys any sort of useful information about the file's purpose.. -- OlliHelenius 2005-11-16 16:59:52
I, and I know of several others, already have a ~/.environment, which is a shell script and not at all suited for parsing by pam_env, so yes, I think using ~/.pam_environment is good. -- TollefFogHeen, 2006-01-03 17:01:52
* If this file is supposed to be edited by end users, I'd like a better name. 'pam' means nothing to most people, and I'd rather have something of the type 'global_config' or 'user_config' - well, I have no great suggestions but you get my drift. A file that could be found and/or recognized even if the user didn't know it's name beforehand. -- KristofferLundén
I'd like a similar feature for Environment Variables. Even though these are slightly more advanced than just "path", sometimes a user is required to set variables. These should work regardless of user's shell (tcsh, bash, ksh, etc). Examples are things like setting SDL_AUDIODEVICE=alsa for games to work with sound. This may also require a mode of "modifying" a system variable, in the case of wanting to add paths to the beginning or end of a list of paths; LD_LIBRARY_PATH. I can imagine this would be for Dapper+1, based on the success o f the path editing. -- PeterShinners 2016-12-05 19:00:31
Just a comment: as a user I would find the name .pam_environment a *very* odd name for the canonical place to put my $PATH. I'm a long-time Unix guy, new to Ubuntu though. I'd be very happy to have a single systemwide and per-user place to put this, so I think this is a good idea. I just question the name. How about .default-environment or .standard-environment instead? To a user, it has nothing to do with pam. And in fact I can't see why pam is involved at all (well, I guess all auth is done via pam now -- but what if pam is replaced someday by some other cool trendy auth layer?). -- Gary Oberbrunner (garyo 2016-12-05 19:00:31)
This can be done with ~/.pam_environment, yes. -- TollefFogHeen 2006-01-03 17:01:52
This now seems to be implemented but not documented. Is .pam_environment imported before or after the global environment settings? Can one safely interploate those values? (PATH $(PATH):$HOME/bin for example) -- peridot 2016-12-05 19:00:31