ayekat / localdir

Personal configuration files
65 stars 3 forks source link

Expand XDG_DATA_DIRS correctly #18

Closed ayekat closed 4 years ago

ayekat commented 7 years ago

Currently I expand XDG_DATA_DIRS in .pam_environment as follows:

XDG_DATA_DIRS DEFAULT="/usr/local/share:/usr/share" OVERRIDE="${XDG_DATA_DIRS}"
XDG_DATA_DIRS DEFAULT="${HOME}/.local/share:${XDG_DATA_DIRS}"

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:

/home/ayekat/.local/share:/home/ayekat/.local/share:/home/ayekat/.local/share:/usr/local/share:/usr/share

See also:

ayekat commented 7 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.

soc commented 7 years ago

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?

ayekat commented 7 years ago

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 ^^)

ayekat commented 4 years ago

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).