~/.pam_environment not parsed by default

When dealing with this bug, it would be great if bug #957431 could be addressed as well. I suppose that the latter bug requires code changes in about the same spot in the source as this one.

Gunnar, is that still an issue?

Yes, it's not resolved yet, and since Robert triaged it, I take it that he agrees.

Right, I was rather trying to figure if now is time to raise a bit priority ... Robert what do you think? That makes incorrect locales to be used and should be fixed for precise no?

I for one think that 12.04 should really not be released with this bug unsolved.

Dera Friends,

My bug, Bug #969666, was marked as a duplicate of this bug.

While I've not been paying attention, the issue was resolved for me, in one of the upgrades, I assume.

Was it resolved for anyone else, please?

Thanks and Blessings,
Shahar

Short answer is it should be able to do this correctly. I haven't investigated why it's occurring, but it might be an ordering issue in PAM (i.e. you need to have the pam_environment run after the ecryptfs module as well as before it)

Shahar,

The reason why I marked your bug report as a duplicate is this line in the description:

  EcryptfsInUse: Yes

Are you really saying that it has started to work for you despite of the encrypted HOME? Or have you started log in as a user whose HOME is not encrypted?

Dear Gunnar,

Thank you for the clarification.

Yes. Changing languages is now successful. I am now using Hebrew in my personal user account, the same user account in which I filed the report, and yes, like the report says, it is under default Ubuntu ecrypts encryption.

Some more analysis of what I remember, trying a different user, which is not in an encrypted home, did NOT have this issue.

Unfortunately, I did not remember if I tested a different, encrypted home, user.

So I don't mind hanging around with you guys but this might not be the same bug :)

Thanks and Blessings,
Shahar

Shahar,
I'm still a little confused. I'd suggest that we wait til the issue in this report has been fixed. Then, if you after that find shortcomings in how the language settings UI work, I'd appreciate a separate bug about it, where you as detailed as possible describe
- which steps you took,
- what you expected to happen, and
- what happended instead.
Would that be ok for you?

On 7 April 2012 19:21, Gunnar Hjalmarsson <email address hidden> wrote:
> Shahar,
> I'm still a little confused. I'd suggest that we wait til the issue in this report has been fixed. Then, if you after that find shortcomings in how the language settings UI work, I'd appreciate a separate bug about it, where you as detailed as possible describe
> - which steps you took,
> - what you expected to happen, and
> - what happended instead.
> Would that be ok for you?

Sure. Thank you!

Hello together,

I think this Bug is available, because I have Ubuntu installed since November and in the interim while a big update is fallen somewhat confused..

If I install a completely different language, such as Icelandic and drag it to first place, me log out and log in, then the language remains in the system yet in English. Only under LightDM is Icelandic correctly.

Hello,

I have edited the file ~/.profile in my home folder and now I have everywhere German language. Following changes in this config file:

export LANGUAGE="de"
export LC_MESSAGES="de_DE.UTF-8"
export LC_CTYPE="de_DE.UTF-8"
export LC_COLLATE="de_DE.UTF-8"
export LANG="de_DE.UTF-8"

It works!

Benjamin,

Are you sure you have
EcryptfsInUse: Yes ?

These settings in ~/.profile have no influence in my system...

Hi Sami,

yes I use ecryptfs. See my duplicate...

You can try to set your system language in gnome-control-center and then remane your ~/.profile to ~/.profile.back and restart. Works?

This bug is set to High importance, triaged and assigned.. As a fix on its way?

Clearly pam_env can't read ~/.pam_environment if $HOME hasn't been mounted yet. Adding pam_env after common-session in lightdm's pam config fixes this and allows me to change the language of my desktop session.

I'm not sure why pam_env would need to be present before ecyptfs (as suggested in comment #7), though?

Had the same problem today without encrypted HOME-folder, but parts of it like dokuments etc. on an other hard-drive.

Anyone have a workaround for this?

Looks like this is a dupe of 584249. There's a workaround in that one, though I haven't tested it myself yet:

session required pam_env.so

Add that line at the end of /etc/pam.d/common-session is supposed to force it to read the ~/.pam_environment afteram encrypted $HOME is mounted.

@dreamon
I marked your bug #993818 a duplicate of this one. Please don't hesitate to remove the duplicate link if you think the cause of the problem lies elsewhere.

I confirmed that the above work-around (adding session required pam_env.so to /etc/pam.d/common-session) works great. Perhaps that's all Ubuntu needs to do to fix this bug? Not sure if there are any negative side effects, but so far I'm not experiencing any.

@David
It works fine for me too, so it seems to be a possible solution. I prepared a merge proposal to have it considered by a core developer.

@Gunnar: Thanks for looking into this and sorry for my late reply. I tested the workaround suggested by David in comment #19 and can confirm that this solved the problem for me. Language Selector works as expected now.

How is ~/.pam_environment is created? Because for example for ssh with encrypted home ~/.ssh/authorized_keys is put outside the encrypted $HOME, not inside it. E.g. one of the tutorials to achieve this is here: https://rohieb.wordpress.com/2010/10/09/84/
Such that one doesn't need to decrypt home to read ~/.pam_environment.

I don't know how it is created, but I think it is more about timing. Perhaps SSH tries to get a file handle to ~/.pam_environment and run it itself at a point in time after the encrypted home has been mounted, whereas perhaps the normal LightDM session login does so too early.

Status changed to 'Confirmed' because the bug affects multiple users.

I can confirm that the issue is present in Ubuntu 12.10 as well.

On 2013-01-15 00:33, Dmitrijs Ledkovs wrote:
> How is ~/.pam_environment is created?

It's created and maintained by the SetLanguage and SetFormatsLocale methods in accountsservice.

> Because for example for ssh with encrypted home
> ~/.ssh/authorized_keys is put outside the encrypted $HOME, not inside
> it. E.g. one of the tutorials to achieve this is here:
> https://rohieb.wordpress.com/2010/10/09/84/
> Such that one doesn't need to decrypt home to read
> ~/.pam_environment.

To me, that approach seems to be somewhat complicated to implement. Do you really think it would be better than the suggested pam solution?

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.

This problem also affects /etc/pam.d/atd, /etc/pam.d/sshd, and /etc/pam.d/sudo in raring.

On 2013-02-12 05:08, Steve Langasek wrote:
> - As of the next upload of pam to raring, .pam_environment will not
> be read by default at all by the pam_env module.

Currently that would break the locale environment for everyone, so please put that upload on hold.

On Tue, Feb 12, 2013 at 04:21:14PM -0000, Gunnar Hjalmarsson wrote:
> On 2013-02-12 05:08, Steve Langasek wrote:
> > - As of the next upload of pam to raring, .pam_environment will not
> > be read by default at all by the pam_env module.

> Currently that would break the locale environment for everyone, so
> please put that upload on hold.

It was already uploaded. But I'm following it up with an upload of lightdm
as well (sorry, already had a branch in progress before your merge proposal
came in - just needed to log out to test it, which I've now done).

Thanks for your guidance, Steve!

I for one understand the implications for login managers, and have submitted merge proposals for lightdm and gdm.

Fixed in lightdm 1.4.0-0ubuntu4.

This bug was fixed in the package gdm - 3.6.1-0ubuntu3

---------------
gdm (3.6.1-0ubuntu3) raring; urgency=low

  * debian/gdm.pam:
    Make pam_env read ~/.pam_environment (LP: #952185). This needs
    to be stated explicitly, since the fix of
    http://bugs.debian.org/611136 is about to make it into Raring.

  [ Steve Langasek ]
  * adjust pam_env handling to match that in lightdm: only call pam_env at
    the end, which lets us call it only twice instead of three times.
 -- Gunnar Hjalmarsson <email address hidden> Tue, 12 Feb 2013 22:27:00 +0100

A Precise build of lightdm with the proposed fix is available in my PPA at https://launchpad.net/~gunnarhj/+archive/misc
Please feel free to install, test, and report possible issues.

Closing some less important tasks.

sudo explicitly says that ~/.pam_environment shall not be read; invalidating the tasks.

@Gunnar: thanks for the work on that issue, for the SRU it would be useful to have a testcase as well so testers know how to verify if the fix is working as it should, could you add it to the bug summary?

Test case added.

This bug was fixed in the package gdm - 3.6.1-0ubuntu4

---------------
gdm (3.6.1-0ubuntu4) raring; urgency=low

  * debian/gdm-autologin.pam:
    Same changes as in debian/gdm.pam; this file was overlooked in
    the fix of LP: #952185 in version 3.6.1-0ubuntu3.
 -- Gunnar Hjalmarsson <email address hidden> Mon, 11 Mar 2013 23:26:00 -0700

Hello Gunnar, or anyone else affected,

Accepted lightdm into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/lightdm/1.2.3-0ubuntu2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

I have installed lightdm 1.2.3-0ubuntu2 from precise-proposed and successfully logged in with lightdm as a user with an encrypted HOME. Now, unlike before, the locale environment is set in accordance with ~/.pam_environment.

(unsubscribing sponsors, the current openssh patch is the only one waiting for upload and Colin said he's reviewing it, so we don't need to keep the entry in the sponsoring queue)

Adding a (Bazaar Explorer generated) patch for the gdm (precise) task.

Applied for my next Debian upload, thanks. Sorry for the delay - I needed to check the source rather closely to make sure this had no unintended side-effects, since I recall this being complicated in the past. But it looks as though this is in fact an otherwise-harmless simplification of the path that PAM environment data takes through sshd.

This bug was fixed in the package openssh - 1:6.1p1-4

---------------
openssh (1:6.1p1-4) experimental; urgency=low

  [ Gunnar Hjalmarsson ]
  * debian/openssh-server.sshd.pam: Explicitly state that ~/.pam_environment
    should be read, and move the pam_env calls from "auth" to "session" so
    that it's also read when $HOME is encrypted (LP: #952185).

  [ Stéphane Graber ]
  * Add ssh-agent upstart user job. This implements something similar to
    the 90x11-common_ssh-agent Xsession script. That is, start ssh-agent
    and set the appropriate environment variables (closes: #703906).

 -- Colin Watson <email address hidden> Mon, 25 Mar 2013 16:58:04 +0000

This bug was fixed in the package lightdm - 1.2.3-0ubuntu2

---------------
lightdm (1.2.3-0ubuntu2) precise-proposed; urgency=low

  [ Steve Langasek ]
  * Update pam configs to call pam_env last and use user_readenv=1
    explicitly, so that ~/.pam_environment can always be read even when
    home directories are encrypted with ecryptfs. LP: #952185.
 -- Gunnar Hjalmarsson <email address hidden> Wed, 11 Mar 2013 23:35:00 -0700

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

I've uploaded the gdm debdiff to Precise, thanks!

there is a new bug reported against the precise version that states that $PATH stopped including /usr/games after the update: bug #1162836

On 2013-04-02 11:35, Sebastien Bacher wrote:
> there is a new bug reported against the precise version that states that
> $PATH stopped including /usr/games after the update: bug #1162836

I could not reproduce that issue. Consequently, right now it seems like that $PATH problem is related to both the fix of this bug and something else. So we need to figure out if the fix of this bug needs to be modified, or if it is "something else" that needs to be fixed.

This bug was fixed in the package at - 3.1.13-2ubuntu2

---------------
at (3.1.13-2ubuntu2) raring; urgency=low

  * pam.conf:
    Explicitly state that ~/.pam_environment shall be read, and move
    the pam_env call to the end so it's read also when $HOME is
    encrypted (LP: #952185).
 -- Gunnar Hjalmarsson <email address hidden> Thu, 14 Feb 2013 10:00:00 +0100

Hello Gunnar, or anyone else affected,

Accepted openssh into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/openssh/1:5.9p1-5ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hello Gunnar, or anyone else affected,

Accepted gdm into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/gdm/3.0.4-0ubuntu15.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

I have installed gdm 3.0.4-0ubuntu15.1 från precise-proposed. When logging in using GDM as a user with encryptfs protected $HOME, and unlike before, the locale environment is set in accordance with ~/.pam_environment.

@ gunnarhj can you test openssh as well?

@Dmitrijs: Sorry, but I don't have a setup for doing so.

I haven't actually been able to reproduce the original problem with openssh. However, I've been able to verify that .pam_environment still works when sshing to the account of a user with $HOME on ecryptfs after installing the new openssh-server package from precise-proposed. Since I'm not convinced that the original behaviour was well-defined, in my opinion regression-testing here is good enough.

This bug was fixed in the package gdm - 3.0.4-0ubuntu15.1

---------------
gdm (3.0.4-0ubuntu15.1) precise-proposed; urgency=low

  * debian/gdm.pam, debian/gdm-autologin.pam:
    Call pam_env at the end, so ~/.pam_environment is read also when
    $HOME is encrypted (LP: #952185).
 -- Gunnar Hjalmarsson <email address hidden> Wed, 13 Feb 2013 22:37:00 +0100

This bug was fixed in the package openssh - 1:5.9p1-5ubuntu1.1

---------------
openssh (1:5.9p1-5ubuntu1.1) precise; urgency=low

  [ Gunnar Hjalmarsson ]
  * debian/openssh-server.sshd.pam: Explicitly state that ~/.pam_environment
    should be read, and move the pam_env calls from "auth" to "session" so
    that it's also read when $HOME is encrypted (LP: #952185).
 -- Colin Watson <email address hidden> Tue, 26 Mar 2013 14:15:06 +0000