Bug 751610 – sys-libs/pam-1.4.0 regression wrt pam_env ~/.pam_environment

• Product: Gentoo Linux
• Status: RESOLVED UPSTREAM

[Description WGH 2020-10-28 16:36:53 UTC]

New release of pam regresed pam_env in two ways:

1) user_readenv is no longer default
2) https://github.com/linux-pam/linux-pam/issues/263

The first issue can be fixed by editing the configuration file, the second one - AFAIK can't be worked around.

Any chance of restoring pre-1.4.0 pam into the portage tree so users could install the old one until regressions are fixed upstream?

[Comment 1 Mikle Kolyada (RETIRED) 2020-10-28 17:35:22 UTC]

For first I have no plan to change the default, for second, well, we can pick the patch if there gonna be, but nothing more.

[Comment 2 WGH 2020-10-29 07:24:20 UTC]

(just in case someone googles this bug report)

Sorry, I accidentally misunderstood the problem.

Altough the linked bug does exists, it only manifests in a limited easily workaroundable circumstatances (missing \n at the end of a line), and I was actually having a different problem.

I was initially trying to make the following work again:

SSH_AUTH_SOCK DEFAULT="${XDG_RUNTIME_DIR}/ssh-agent.socket"

I added user_readenv=1 back, but $XDG_RUNTIME_DIR expanded to an empty string. Turned out I was adding it to the "session required pam_env.so" line in system-auth, which is logically the right place, but it was before the "-session  option pam_systemd.so" line.

So in order to use $XDG_RUNTIME_DIR in your ~/.pam_environment, pam_env.so user_readenv=1 must come after pam_systemd.so.

I believe pam_env.so used to be called lots of times, all with user_readenv=1, and some of the calls happen after systemd sets XDG_ stuff.

Still, user_readenv=1 default was probably removed for a reason, so I don't advise anyone to blindly reenable it back.