pam_env(sshd:session): deprecated reading of user environment enabled

[Romwriter]

Ubuntu 24.04 / openssh-server/noble-updates 1:9.6p1-3ubuntu3

sshd complains about "deprecated reading of user environment".

This should have been solved upstream, as far as I understand: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018106

Enclosed /etc/pam.d/sshd file is amended according to the debian bug report.

ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: openssh-server 1:9.6p1-3ubuntu3
ProcVersionSignature: Ubuntu 6.8.0-11.11-generic 6.8.0-rc4
Uname: Linux 6.8.0-11-generic x86_64
ApportVersion: 2.28.0-0ubuntu1
Architecture: amd64
CasperMD5CheckResult: unknown
Date: Sun Mar 31 11:56:25 2024
ProcEnviron:
 LANG=de_DE.UTF-8
 PATH=(custom, no user)
 SHELL=/bin/bash
 TERM=xterm-256color
 XDG_RUNTIME_DIR=<set>
SourcePackage: openssh
UpgradeStatus: No upgrade log present (probably fresh install)
modified.conffile..etc.init.d.apport: [modified]
mtime.conffile..etc.init.d.apport: 2024-02-22T15:20:00
mtime.conffile..etc.pam.d.sshd: 2024-03-31T11:56:12.949543

[Andreas Hasenack (ahasenack)]

Fixing this in noble at this time will require a feature freeze exception, because we would be changing behavior.

The default for user_readenv in pam_env is 0 (off). In the sshd config, ubuntu/debian ship a pam config that sets it to on (1), therefore ~/.pam_environment will be read if it exists.

Upstream has flagged that this feature (of reading user-provided env var files) will be removed in the future, and is thus catching the setting of user_readenv=1 and showing the deprecation notice warning. To get rid of the warning, we have to stop setting user_readenv=1, which will *disable* the feature. Meaning, in noble, if we make this change, ~/.pam_environment (or the file specified by user_envfile) will NOT be read anymore.

Upstream marked this deprecation in version 1.5.0, which means ubuntu Mantic and Noble are affected.

Now is the right time to make this change: mantic had the deprecation notice already, and noble is an LTS.

[Andreas Hasenack (ahasenack)]

Deprecation warning introduced here: https://github.com/linux-pam/linux-pam/releases/tag/v1.5.0

Release notes for all releases up to 1.6.1 don't mention this again, so it's still there: https://github.com/linux-pam/linux-pam/releases

[Andreas Hasenack (ahasenack)]

Commit that added the warning to pam_env.c: https://github.com/linux-pam/linux-pam/commit/ecd526743a27157c5210b0ce9867c43a2fa27784

[Andreas Hasenack (ahasenack)]

We won't fix this in openssh for Ubuntu 24.04 due to the change in behavior that it introduces at this stage in the cycle, but it should be fixed in 24.10.

As for 24.04, what we will attempt to do is suppress the pam_env warning in the src:pam package.

[Andreas Hasenack (ahasenack)]

New pam package uploaded to noble-proposed. It's in the unapproved queue.

[Launchpad Janitor (janitor)]

This bug was fixed in the package pam - 1.5.3-5ubuntu5

---------------
pam (1.5.3-5ubuntu5) noble; urgency=medium

  * d/p/pam_env-remove-deprecation-notice-for-user_readenv.patch: drop
    deprecation warning about user_readenv from pam_env (LP: #2059859)

 -- Andreas Hasenack <email address hidden> Wed, 10 Apr 2024 16:19:22 -0300

[Bryce Harrington (bryce)]

Looks like this is the section that would need changed?

### d/openssh-server.sshd.pam.in

# Read environment variables from /etc/environment and
# /etc/security/pam_env.conf.
session required pam_env.so # [1]
# In Debian 4.0 (etch), locale-related environment variables were moved to
# /etc/default/locale, so read that as well.
session required pam_env.so user_readenv=1 envfile=/etc/default/locale

Is it just the "user_readenv=1" that needs dropped or would the entire line need to drop?

From git blame this was added in 1:6.1p1-4 due to LP: #952185 in relation to encrypted home directories. Would any of that need revisited?

[Andreas Hasenack (ahasenack)]

> 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

[Andreas Hasenack (ahasenack)]

Regarding the LC_* variables in openssh's config, I understand it's not a direct replacement for ~/.pam_environment, because that is on the *server*, and we would be sending the *client* vars.

[Andreas Hasenack (ahasenack)]

Adding a task for gdm3, since it seems affected by dropping user_readenv=1 from its pam configuration.

[Sebastien Bacher (seb128)]

Thanks Andreas for ping us about the issue. We have work to do there on the desktop side since language-selector is currently relying on that feature

Some reference
/usr/share/language-tools/save-to-pam-env provided by https://git.launchpad.net/ubuntu/+source/accountsservice/tree/debian/patches/0009-language-tools.patch?h=ubuntu/oracular

https://git.launchpad.net/ubuntu/+source/language-selector/tree/LanguageSelector/LocaleInfo.py?h=ubuntu/oracular#n231

https://salsa.debian.org/gnome-team/gdm/-/blob/ubuntu/latest/debian/patches/ubuntu/dont_set_language_env.patch

We need to investigate what to do instead, I will put that on the desktop backlog

[Steve Langasek (vorlon)]

On Wed, Jul 10, 2024 at 02:23:27PM -0000, Sebastien Bacher wrote:
> Thanks Andreas for ping us about the issue. We have work to do there on
> the desktop side since language-selector is currently relying on that
> feature

Yes, there is not a clear replacement for ~/.pam_environment wrt setting
environment variables in all the same session contexts.

There may be a systemd equivalent but I don't know specifically what it
would be. Subscribing Nick for comment.

[Launchpad Janitor (janitor)]

This bug was fixed in the package openssh - 1:9.6p1-3ubuntu17

---------------
openssh (1:9.6p1-3ubuntu17) oracular; urgency=medium

  * Remove deprecated user_readenv=1 setting (LP: #2059859):
    - d/openssh-server.sshd.pam.in: drop user_readenv=1, which was
      deprecated by pam_env upstream. Openssh has the SendEnv and
      AcceptEnv configuration options that can be used to replace this
      feature, and are in the default config already
    - d/NEWS: update about this change in behavior

 -- Andreas Hasenack <email address hidden> Wed, 10 Jul 2024 11:41:37 -0300