© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
> Is it just the "user_readenv=1" that needs dropped or would the entire line need to drop?
Just user_readenv=1 needs to go.
Bug LP: #952185 stated that ~/.pam_environment should be read, and the example they gave was locale settings. It's as if back then, the per-user locale variables were set via ~/.pam_environment, or so I understood.
For openssh, the fix back then was two-fold:
a) move pam_env to the end(ish) of session stack, so that if encrypted home directories were used, by then the home directory would be unlocked already. It's now just before pam_selinux, which is the last one, and way after @common-session, which is where the unlocking of the encrypted home directory would occur.
b) add user_readenv=1, which was missing
I just checked in noble, and logging in as a non-admin user, switched my language settings to english UK. Logged out, then back in, and indeed, something created ~/.pam_environment. Which tells me other parts of the system STILL, in 2024, expect that file to be read. Specifically, something in the desktop (gnome/mutter).
For ssh, that might be irrelevant because at least nowadays we have this setting in the sshd_config:
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
And this on the ssh_config (client) one:
Host *
(...)
SendEnv LANG LC_*
But even if we can drop user_readenv=1 from sshd's config (and I think we can), the same cannot be said for other login components of the system. A quick grep on my mantic desktop shows that gdm is the other big app that relies on user_readenv=1.
And indeed, logging in on mantic, I get this deprecation warning in the logs from gdm's usage of pam_env:
2024-07-
...
2024-07-