pam environment duplicate path directories since it is called without user_readenv=0

Bug #955032 reported by linuxar on 2012-03-14
This bug affects 6 people
Affects Status Importance Assigned to Milestone
pam (Ubuntu)

Bug Description

I am trying to set my Environment variables through the procedure described in:

(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:

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: the user_readenv=0 parameter is not specified in the lines where is called inside *all* the files in /etc/pam.d

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 " envfile=/etc/default/locale" was encountered.

For example, in "cron" file, I had to change:

session required envfile=/etc/default/locale


session required envfile=/etc/default/locale user_readenv=0

and this goes the same for all other files inside /etc/pam.d/ folder that contain the line " envfile=/etc/default/locale"

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

Steve Langasek (vorlon) wrote :

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.

Changed in pam (Ubuntu):
importance: Undecided → Low
status: New → Triaged
linuxar (linuxar) wrote :

Sorry, I was not very explicit about the underlying cause. It appears on the link that I gave (, namely in the post (and the answer) gave by Nick Taylor:

"The problem seems to stem from the fact that pam_env defaults to reading the user ~/.pam_environment every time it is invoked. A lot of login methods (cron, lightdm, lightdm-autologin, login, sshd and su on my machine) invoke pam_env twice: once to read the /etc/environment and ~/.pam_environment files, and once to read the /etc/default/locale file. In neither case is the user_readenv flag set, so pam_env reads, and acts on, your ~/.pam_environment twice."

Thank you for taking this issue into consideration. I was wondering if the parameter "user_readenv=0" could not be put directly into the /etc/default/locale file.

Anyway, thanks again.

Steve Langasek (vorlon) on 2013-02-12
Changed in pam (Ubuntu):
status: Triaged → Fix Committed
Launchpad Janitor (janitor) wrote :
Download full text (3.7 KiB)

This bug was fixed in the package pam - 1.1.3-8ubuntu1

pam (1.1.3-8ubuntu1) raring; urgency=low

  * Merge from Debian unstable, remaining changes:
    - debian/libpam-modules.postinst: Add PATH to /etc/environment if it's
      not present there or in /etc/security/pam_env.conf. (should send to
    - debian/libpam0g.postinst: only ask questions during update-manager when
      there are non-default services running.
    - debian/libpam0g.postinst: check if gdm is actually running before
      trying to reload it.
    - debian/libpam0g.postinst: the init script for 'samba' is now named
      'smbd' in Ubuntu, so fix the restart handling.
    - Change Vcs-Bzr to point at the Ubuntu branch.
    - debian/patches-applied/series: Ubuntu patches are as below ...
    - debian/patches-applied/ubuntu-rlimit_nice_correction: Explicitly
      initialise RLIMIT_NICE rather than relying on the kernel limits.
    - debian/patches-applied/pam_umask_usergroups_from_login.defs.patch:
      Deprecate pam_unix' explicit "usergroups" option and instead read it
      from /etc/login.def's "USERGROUP_ENAB" option if umask is only defined
      there. This restores compatibility with the pre-PAM behaviour of login.
    - debian/patches-applied/pam_motd-legal-notice: display the contents of
      /etc/legal once, then set a flag in the user's homedir to prevent
      showing it again.
    - debian/update-motd.5, debian/libpam-modules.manpages: add a manpage
      for update-motd, with some best practices and notes of explanation.
    - debian/patches/update-motd-manpage-ref: add a reference in pam_motd(8)
      to update-motd(5)
    - debian/local/common-session{,-noninteractive}: Enable pam_umask by
      default, now that the umask setting is gone from /etc/profile.
    - debian/local/pam-auth-update: Add the new md5sums for pam_umask addition.
    - Build-depend on libfl-dev in addition to flex, for cross-building
    - Add /usr/local/games to PATH. LP: #110287.

pam (1.1.3-8) unstable; urgency=low

  * Confirm NMU for bug #611136; thanks to Michael Gilbert.
    - As a side effect, there will no longer be errors from reading the
      .pam_environment twice since we are now reading it 0 times.
      LP: #955032.
  * Adjust the pam_env documentation to match the module behavior resulting
    from the previous security upload. Closes: #693995.
  * debian/rules: never regenerate manpages at build time; this may cause
    build skew that breaks the world in a multiarch context. LP: #1095887.
  * debian/patches-applied/glibc-2_16-compilation-fix.patch: fix missing
    include causing build failure with eglibc 2.16. Thanks to Daniel
    Schepler <email address hidden>. Closes: #693450.
  * Ditch autoconf patch in favor of a build-dependency on dh-autoreconf,
    which will let us keep up-to-date with newer autotools. In the present
    instance, this gets us aarch64 support.
  * Install pam_timestamp_check - and while we're at it, move the manpage
    to the correct binary package. Closes: #648695.
  * Update lintian overrides to suppress some noise about hardening and
  * Enable audit support, by popul...


Changed in pam (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers