> 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-10T10:54:54.270057-03:00 nsnx2 gdm-launch-environment]: pam_env(gdm-launch-environment:session): deprecated reading of user environment enabled
...
2024-07-10T10:55:05.512619-03:00 nsnx2 gdm-password]: pam_env(gdm-password:session): deprecated reading of user environment enabled
> 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- 10T10:54: 54.270057- 03:00 nsnx2 gdm-launch- environment] : pam_env( gdm-launch- environment: session) : deprecated reading of user environment enabled 10T10:55: 05.512619- 03:00 nsnx2 gdm-password]: pam_env( gdm-password: session) : deprecated reading of user environment enabled
...
2024-07-