Control: clone -1 Control: reassign -2 release-notes Control: retitle -2 release-notes: document deprecation of .pam_environment
On Sun, Jan 15, 2023 at 04:55:10PM +0300, Michael Tokarev wrote: > On Sun, 28 Aug 2022 07:58:19 +0200 Francesco Potortì <poto...@isti.cnr.it> > wrote: > > My log is full of these: > > sshd[4180530]: pam_env(sshd:session): deprecated reading of user > > environment enabled > > This comes from /etc/pam.d/sshd: > session required pam_env.so user_readenv=1 envfile=/etc/default/locale > > I'm not sure this is sshd issue or pam issue really: if it is deprecated > in pam_env, sshd should not be using it, or it should not be deprecated. > > Removing user_readenv=1 fixes this. There's now https://salsa.debian.org/ssh-team/openssh/-/merge_requests/21 for this, but as noted there I have documentation concerns about simply removing this. Copying my comments from there: This is going to have extensive fallout, the exact nature of which is hard to predict. So far this deprecation has been the equivalent of posting a notice in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "Beware of the Leopard". The Debian PAM packages don't ship the upstream NEWS file, and even if they did, the notice there is extremely brief. You can see a deprecation warning if you read /var/log/auth.log, but who has time for that unless something is going wrong? Besides, the people who are most affected will be users who have .pam_environment files in their home directories, and as far as I can tell nobody has gone to any particular effort to notify them. At a bare minimum, this needs an entry in debian/NEWS. But I'd go further: I think this should be documented in Debian's release notes (repository at https://salsa.debian.org/ddp-team/release-notes) for a release before we make this change. That won't inform everyone, but it should reduce the number of people caught unawares by this. Any other practical ideas for informing affected users would be welcome. Also, we need to track down an actual reason for this change. "Security concerns" is not verbose enough to be convincing on its own. I found https://github.com/linux-pam/linux-pam/commit/ecd526743a27157c5210b0ce9867c43a2fa27784, which is not much better ("Due to problematic security ..."). My best guess is that upstream got fed up after dealing with things like https://github.com/linux-pam/linux-pam/issues/263, but I'm really just guessing, and proper documentation would actually explain this sort of thing rather than just waving a security flag. I'm cloning this bug for the release notes, and CCing the PAM maintainer for comments. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
