Normally, services started with Systemd are given a "clean" environment that does not inherit from the user session. This is by design and it is a good default.
However, I've written some services for myself (e.g. ~/.config/systemd/user/foo.service) where it would be convenient to inherit the environment variables I set up in my X session, such as XDG_DATA_HOME.
I do not want to have to hard code the values of environment variables into each service.
Is there some way to indicate to systemd that I do want to inherit the environment in which user services are started?
Or at least (and maybe better) can I whitelist specific environment variables to be inherited?
Currently my environment variables are configured in a POSIX shell script that I source in both ~/.xsessionrc (and its non-Debian equivalents) for X and ~/.profile for the shell.
If it helps, I am willing to move this config to ~/.pam_environment, but this will require some fragile hacking. My OS-provided (Debian) configuration for my chosen display manager (LightDM) sets user_readenv=0 in pam_env.so, so I would have to make a systemwide configuration change that I would then have to worry about keeping synchronized and correct after package updates.
Of course, I could submit a patch to the Debian package that changes this default, but it's probable that the default is the way it is for a good reason, and I doubt my own selfish use case would be enough to convince them to except such a patch.
Another option is to change from ExecStart=foo -a -b to ExecStart=sh -c 'exec foo -a -b'. This is somewhat distasteful, because I have had problems in the past with Systemd losing track of the foo process, thinking it had successfully exited when in fact it had crashed with a non-zero exit status. Maybe I "did it wrong" and could try it again. But this feels like even more of a kludge than using PAM env, and I'd prefer to avoid it if possible.