systemd does not read .pam_environment

[farsil]

Submission type

• Bug report
• Request for enhancement (RFE)

systemd version the issue has been seen with

$ systemctl --version
systemd 232
+PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN

Used distribution

$ cat /proc/version
Linux version 4.8.11-1-ARCH (builduser@tobias) (gcc version 6.2.1 20160830 (GCC) ) #1 SMP PREEMPT Sun Nov 27 09:26:14 CET 2016

Expected behaviour you didn't see

I overrode $XDG_CONFIG_HOME in my .pam_environment file like this:

XDG_CONFIG_HOME DEFAULT=@{HOME}/.local/etc

Since systemd reports to obey the XDG Path specification I was expecting that it would look for unit files in the overridden path.

Unexpected behaviour you saw

systemd insists in looking for unit files in ~/.config.

Steps to reproduce the problem

Add the line XDG_CONFIG_HOME DEFAULT=@{HOME}/.local/etc to ~/.pam_environment and restart the user session or reboot the system.

[poettering]

Hmm, I presume ~/.pam_environment is a file read by the pam_env module? Is that even enabled on your distro for the systemd user session?

Closing this, as systemd is not in the business of reading ~/.pam_environment, as that's not a generic configuration file, but something some PAM module which might or might not be installed is supposed to read... This all looks like a local misconfiguration. Please investigate, and make sure to file a bug against your distro or pam_env, but not systemd.

[farsil]

Hmm I poorly chose the words for my bug report title. I apologize for that.

The file .pam_environment is being read by pam_env. I know that because the appropriate environment variables are being set (in my case, $XDG_CONFIG_HOME).

The thing is, I expected that the systemd --user instance spawned on login would look for customized unit files in the updated $XDG_CONFIG_HOME but it doesn't. Is there a particular reason why it works this way? Are you sure it is a misconfiguration problem?

[poettering]

did you check that $XDG_CONFIG_HOME is actually set for the systemd --user instance? i.e. that it is shown in /proc/$PID/environe of the instance?

[farsil]

That's the point, it is not set. It's like the systemd --user process is spawned before pam_env has the opportunity to read the user environment variables. You think this is a distribution issue?

[poettering]

This really looks as if you don# actually have pam_env in your pam stack for systemd --user. It's not listed in /etc/pam.d/systemd-user, is it?

[martinpitt]

At least in Debian/Ubuntu, /etc/pam.d/systemd-user does not contain pam_env.so, so I suggest checking that first.

[farsil]

Yeah, that was it. Sorry for the inconvenience, I know this is not an helpdesk.

Keep up the good work.

[kumikooumae]

I found this thread from search engine, and thanks for your hint, I put pam_env.so in /etc/pam.d/systemd-user to let systemd read my env in /etc/security/pam_env.conf. It helped me solve the following problems:

1. Systemd components not reading my env, like autostart in Autostart not working in KDE with systemd boot after changing my $XDG_CONFIG_HOME #20049
2. Systemd did not find my user units in $XDG_CONFIG_HOME/systemd/user/ when I changed $XDG_CONFIG_HOME, even though systemctl --user show recognizes that environment variable
3. My user units not reading my env, even though systemctl --user show recognizes that environment variable

I would suggest systemd to try to read /etc/security/pam_env.conf, as users would expect that after they read archlinux wiki and write environment variables in that file.

---

Below is my workaround solution:
I'm using Fedora and it doesn't have /etc/pam.d/systemd-user. I copied /usr/lib/pam.d/systemd-user to /etc/pam.d/systemd-user and add session required pam_env.so to the end of the file, and it worked.