pam environment duplicate path directories since it is called without user_readenv=0
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
pam (Ubuntu) |
Fix Released
|
Low
|
Unassigned |
Bug Description
I am trying to set my Environment variables through the procedure described in: https:/
(BTW, that page states that ~/.pam_environment: "It is not a script file, but rather consists of assignment expressions, one per line.", which is misleading since it allows one believe that the syntax is the same as of /etc/environment file, which is not tru. ~/.pam_environment uses the pam_env.conf syntax, as specified here: http://
However, back to the bug: basically, I added (prepended) some directory to the ${PATH} variable inside my .pam_environment file and that folder was duplicated in the final PATH variable.
The reason is that (see also: http://
Basically, after creating my .pam_environment file, I had to go inside /etc/pam.d and to scan all files and to add the "user_readenv=0" parameter to every line where "pam_env.so envfile=
For example, in "cron" file, I had to change:
session required pam_env.so envfile=
into:
session required pam_env.so envfile=
and this goes the same for all other files inside /etc/pam.d/ folder that contain the line "pam_env.so envfile=
That's annoying. Please update those files to contain, by default, "user_readenv=0", to avoid duplicate folders when setting $PATH through the .pam_environment file.
Related branches
Changed in pam (Ubuntu): | |
status: | Triaged → Fix Committed |
I had a hard time understanding this at first, until I understood that this was about the fact that pam_env is called *twice* for some services. Yes, we shouldn't be reading the user environment twice; I'm not sure if user_readenv should default to off when 'envfile' is set, or if this should be fixed in the individual packages providing the configs.
There's also a related issue that upstream has turned user_readenv off by default in the latest releases due to security concerns, and we should probably follow suit.