env not changed in acc. with ~/.pam_environment if /home is on nfs

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

Hi Christian,
Thanks for your help to make Ubuntu better by reporting this issue.

Can you please attach /var/log/lightdm/lightdm.log

Are you sure it's not a timing problem? I mean, if the attempt to write to ~/.pam_environment happens before /home is mounted, it won't work, of course. Bug 957431 may be of interest.

It's not a timing problem, because it works with no_root_squash in nfs

lightdm log in attachment

Thanks,
Christian

Thanks for the additional info, Christian.

The failed file test that results in the warning "not access to HOME yet so language not saved" happens in accountsservice and is certainly made as root. So I wrote a patch that makes that code be run as user instead.

I applied the patch in a branch which was uploaded to my PPA at https://launchpad.net/~gunnarhj/+archive/misc
Raring builds of the branch should be available in a couple of hours.

It would be great if you or somebody else with HOME on NFS could install that accountsservice package on a Raring system, so we can find out if the change makes a difference.

The attachment "accountsservice_lp-1083605.diff" of this bug report has been identified as being a patch in the form of a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-sponsors team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

Thanks Gunnar, do you think that this will be backported to LTS , since we are deploying ~2k workstation with it? If not, a simple package rebuild for LTS of your patched version could work?

Thanks!

@Christopher
Well, to begin with we need to know that the patch actually fixes the issue. Are you implicitly saying that you tested the PPA build successfully?

If it works, I'm going to nominate it for SRUs of Precise and Quantal.

We're just tested it building on LTS, doesnt' work. Full report and details are coming next.

The log for our test in LTS.

It doesn't work with the patch. We applied it, rebuilt and installed the package. After a reboot, the new language seems to be chosen, with no error in log, but environment doesn't change and interface is still in english, as previously.

Thanks,
Christian

And this is the environment.

Thanks for testing. I suppose you noticed that the code is different in Precise, and modified the patch accordingly.

In any case it's promising that no warning message is written to the log. Can you please show the output from the command:

cat ~/.pam_environment

I suspect that the other (more serious) problem is related to bug #952185, and there is a proposed solution to it.

This is the .pam_environment after choosing the italian
localization:

$ cat .pam_environment
LC_NUMERIC=it_IT.UTF-8
LC_TIME=it_IT.UTF-8
LC_MONETARY=it_IT.UTF-8
LC_PAPER=it_IT.UTF-8
LC_NAME=it_IT.UTF-8
LC_ADDRESS=it_IT.UTF-8
LC_TELEPHONE=it_IT.UTF-8
LC_MEASUREMENT=it_IT.UTF-8
LC_IDENTIFICATION=it_IT.UTF-8
LANGUAGE=it:es_ES:de_DE:en
LANG=it_IT.UTF-8

Thanks, Christian, it confirms that LANGUAGE and LANG were updated as expected.

As for the remaining problem (that ~/.pam_environment is ignored), can you please add the line

session required pam_env.so

to the bottom of /etc/pam.d/common-session, and let us know if it makes a difference.

Added as:

$ tail /etc/pam.d/common-session
# /etc/login.defs and user settings, solving the problem of different
# umask settings with different shells, display managers, remote
sessions etc.
# See "man pam_umask".
session optional pam_umask.so
# and here are more per-package modules (the "Additional" block)
session required pam_unix.so
session [success=ok default=ignore] pam_ldap.so minimum_uid=1000
session optional pam_ck_connector.so nox11
# end of pam-auth-update config
session required pam_env.so

but still having english when choosing german, and also now:

$ cat .pam_environment
LC_NUMERIC=it_IT.UTF-8
LC_TIME=it_IT.UTF-8
LC_MONETARY=it_IT.UTF-8
LC_PAPER=it_IT.UTF-8
LC_NAME=it_IT.UTF-8
LC_ADDRESS=it_IT.UTF-8
LC_TELEPHONE=it_IT.UTF-8
LC_MEASUREMENT=it_IT.UTF-8
LC_IDENTIFICATION=it_IT.UTF-8
LANGUAGE=de_DE:fr:es_ES:it:en
LANG=de_DE.UTF-8

the LC_* are not changed.

It was disappointing, and a little strange, since that solution makes a difference when HOME is encrypted.

Just to be sure: Did you reboot after adding that line?

I wonder ... could it be that also PAM acts as root when reading ~/.pam_environment, and that there is a need to change PAM in a similar way as I propose for accountsservice?

Is ~/.pam_environment world readable?

At this time, it seems there is no confirmed working fix for this bug.
I am unsubscribing ubuntu-sponsors team, for now.
When there is a finalised patch to sponsor, please resubscribe ubuntu-sponsors team.

<GunnarHj> xnox: It's about bug 1083605. I'm pretty sure it's a two step problem, and that the patch solves the first one.
<ubottu> Launchpad bug 1083605 in accountsservice (Ubuntu) "accountsservice doesn't set locale choice if /home is on nfs" [Undecided,In progress] https://launchpad.net/bugs/1083605
<GunnarHj> xnox: That would take care of the accountsservice issue. The rest of the problem lies elsewhere, possibly in pam.
<xnox> GunnarHj: ok. So you want that patch for raring. But is that patch useful on it's own as an SRU? Or will the SRU wait for a more comprehensive fix, e.g. together with a pam fix?
<GunnarHj> xnox: No, let's stick with raring for now.
<xnox> GunnarHj: ack.

Subscribing sponsors team for the currently proposed patch into raring.

Debdiff looks good. ACK. Uploading to raring now. Thanks!

This bug was fixed in the package accountsservice - 0.6.29-1ubuntu4

---------------
accountsservice (0.6.29-1ubuntu4) raring; urgency=low

  * debian/patches/0010-set-language.patch:
    Run user_HOME_available() as user in order to prevent incorrect
    failures when HOME is on NFS (LP: #1083605).
 -- Gunnar Hjalmarsson <email address hidden> Wed, 23 Jan 2013 08:19:27 -0500

While the accountsservice fix has now been uploaded to Raring, and if I understand it correctly, there is at least one remaining issue. I changed the summary of this bug report to reflect that issue, and added a pam task.

Further participation by NFS users is essential to resolve this bug. For instance, is also the failure to parse ~/.pam_environment related to whether the no_root_squash option is enabled, i.e. does it work with that option but not otherwise?

Also, can someone please unsubscribe ubuntu-sponsors, since there is currently nothing to sponsor.

Well, I suppose we want to call setfsuid() before trying to read ~/.pam_environment from pam_env; that probably explains any failures to read it when /home is on NFS (with root squash).

Unsubscribing sponsors.

On 2013-01-23 22:57, Steve Langasek wrote:
> Well, I suppose we want to call setfsuid() before trying to read
> ~/.pam_environment from pam_env;

If I understand the code correctly, handle_env() in modules/pam_env/pam_env.c calls pam_modutil_drop_priv() in libpam/pam_modutil_priv.c where setfsuid() is called.

In the accountsservice fix of this bug we call setresuid(), and that seems to make a difference on NFS.

Yes, setresuid() does make a difference over NFS, but it's the wrong interface. You should be using setfsuid(), *not* setresuid().

If pam_env is already calling setfsuid() (which makes sense, as this is mature and well-exercised code, including on NFS), then I don't know of any other reason for the module to fail to read ~/.pam_environment on NFS. Someone who can reproduce this will need to trace the issue to see what's happening.

On 2013-02-02 09:24, Steve Langasek wrote:
> Yes, setresuid() does make a difference over NFS, but it's the wrong
> interface. You should be using setfsuid(), *not* setresuid().

Sorry, but that distinction is above my head. You may want to fight with pitti about it (he suggested setresuid() when sponsoring the accountsservice code). ;-)

> If pam_env is already calling setfsuid() (which makes sense, as this is
> mature and well-exercised code, including on NFS),

That's what I found from reading the code, at least (when I was about to write a patch...). But I may have missed something.

> Someone who can reproduce this will need to trace the issue to see
> what's happening.

Right.

Bug 1156670 with a similar issue as this one, not to say a duplicate, has been successfully resolved. The discussion at the other bug on possible causes why ~/.pam_environment appeared to be ignored may be of interest.

It would be great if we could close this bug as a result of a working solution.

Hello Christian, or anyone else affected,

Accepted accountsservice into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/accountsservice/0.6.15-2ubuntu9.6 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!

As regards the verification of accountsservice 0.6.15-2ubuntu9.6 from precise-proposed, please see
https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1156670/comments/17

Verification needs to be done on the packages in proposed, not from a PPA.

@Scott: Then please see
https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1156670/comments/18
;-)

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.

This bug was fixed in the package accountsservice - 0.6.15-2ubuntu9.6

---------------
accountsservice (0.6.15-2ubuntu9.6) precise-proposed; urgency=low

  * debian/patches/0010-set-language.patch:
    Run user_HOME_available() as user in order to prevent incorrect
    failures when HOME is on NFS (LP: #1083605, LP: #1156670).
 -- Gunnar Hjalmarsson <email address hidden> Tue, 19 Mar 2013 08:32:00 +0100

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release