Re: Systemd user environment variables not picked up for me
On Mon, Jun 29, 2020 at 05:19:49PM +0200, l0f4r0@tuta.io wrote:
> I'm not sure to understand what you want to achieve exactly, but aren't you
> supposed to use pam_env for setting/unsetting your environment variables?
We can only speculate about the OP's actual goal, but I'll tell you
what *I* was hoping to achieve when I looked into this stuff a while
back.
The holy grail, for me, would have been a way to specify environment
variables that are applied to all user logins, whether by console login,
or ssh, or Display Manager, independent of the user's login shell.
And those variables must include a way to reference existing shell
variables like $HOME, so that one can (for example) set MAIL=$HOME/Maildir/
somewhere and have it actually *work*.
pam_env gives us the /etc/environment file which is potentially useful,
as it does in fact support many of the features I was looking for. But
you cannot use reference to other shell variables there. If you put
MAIL=$HOME/Maildir/ in /etc/environment and login, you will have the
literal characters $ H O M E in the resulting variable.
Even more subtly, it turns out that at the time this particular PAM
module runs, the HOME variable isn't even *set* yet. So, even if you
used some module that can use existing variables, it wouldn't help
for this. (Yes, I went down that pathway too.)
When I investigated environment.d, I was hoping that it could replace
pam_env and actually support the setting of environment variables in
user login sessions, including references to basic common variables like
HOME and LOGNAME. The man page *looks* promising, even supporting some
of the fancier shell expansions like ${VAR:-default}.
It turns out that this environment.d thing is only used for "services",
not user logins. Who cares about "services"? If you need a variable to
be defined for a service to run, you'll set it in the service's unit file,
or you'll have a config file full of all the variables this service needs.
You don't need to use environment.d for that. You don't *want* to use
environment.d for that. Using environment.d would set the same variables
in every service. Who does that? What kind of setup would involve such
a thing?
So, in the end, the only way to add nontrivial, real-life variables to
all user logins is to configure *every* possible login vector and shell
individually. There has been less than zero progress on this front in
30 years.
Reply to: