Closed ayekat closed 4 years ago
There is systemd-environment-d-generator, which allows environment variable expanding, but has another issue instead: the chicken-or-egg problem hinted at in https://github.com/linux-pam/linux-pam/issues/7: it reads its configuration from XDG_CONFIG_HOME/environment.d/*.conf
. We would need to set XDG_CONFIG_HOME
somewhere else first (or keep around a ~/.config
directory just for this).
One approach would be to use ~/.pam_environment
to only set XDG_CONFIG_HOME
, then use systemd to generate the rest of the environment.
Needless to say, that would be very ugly.
Hez @ayekat, I wonder whether it would be practical to add the desired path from which systemd/linux-pam reads its config file to the comment field of /etc/passwd
and patch those applications to use it?
Hey @soc, thanks for your comment!
That would indeed be a very elegant solution: It would be stored in a pretty standard system-wide location (so the "bootstrapping issue" wouldn't exist), while the user would still have the possibility to adjust it (similar to using passwd
or chsh
).
I would even go further and claim that adding a new field to /etc/passwd
would be more elegant (but here we'd be fighting a lot of "legacy weight") :smile:
(that being said, even if we patched PAM to support that field/comment, it would still not solve my issue here, namely that the pam_env syntax is horrible ^^)
As I'm no longer using XDG_DATA_DIRS
(and it generally appears the …_DIRS
variables are only meant for system-wide stuff under /etc
or /usr
), I'm going to close this issue.
The issue of PAM being very limited for doing this sort of thing remains, but it's being tracked in the appropriate place (their GitHub project issue tracker).
Currently I expand
XDG_DATA_DIRS
in.pam_environment
as follows:This, however, results in
${HOME}/.local/share
being prepended 3 times to/usr/local/share:/usr/share
. I assume that this is just due to an endless "re-triggering" of assignments, which is aborted by PAM after 3 iterations:See also: