Comment 29 for bug 952185

Revision history for this message
Steve Langasek (vorlon) wrote : Re: ~/.pam_environment not parsed when HOME is encrypted

Having reviewed the proposed pam change at <https://code.launchpad.net/~gunnarhj/ubuntu/raring/pam/encrypted-home/+merge/135021>, I believe it's incorrect and that this needs to be fixed in lightdm instead. Repeating my comment from the merge proposal:

 - This is a change in behavior of common-session for all PAM services. Previously, pam_env is not mentioned in the common-* files at all, only in select service files that wish to use the module. Maybe this should be a common module, but I think that's separate from the question of hether the existing services have a correct stack, and this should not be the solution for the reported bug.
 - The services that are having this problem are ones that don't have pam_env in their session stack /at all/ - they're calling pam_env as an 'auth' module. This is allowed by the module, but should be considered deprecated. Furthermore, the module's own manpage says "Since setting of PAM environment variables can have side effects to other modules, this module should be the last one on the stack." So the services currently including pam_env appear to be misusing it; they should be fixed directly.
 - As of the next upload of pam to raring, .pam_environment will not be read by default at all by the pam_env module. This change is being made in response to CVE-2010-4708, a low-priority security bug that can cause unexpected side effects on other modules later in the stack. Explicitly putting pam_env last in the session stack and using user_readenv=1 should be safe; but that would need to be done in the per-service configs to ensure that it's actually last.

So I don't think this should be implemented in its current form and think that this needs to be fixed in the per-service files instead.