Make environment variables from */environment.d/*.conf visible in login sessions

[preinkemeier]

Submission type

• Request for enhancement (RFE)

systemd version the issue has been seen with

235

Used distribution

Archlinux

Remarks

Since version 233 systemd gained support for environment generators. The user environment generator shipped with systemd sets up environment variables based on files dropped into /etc/environment.d and ~/.config/environment.d/. Now there are at least three different way to configure environment variables:
The user environment generator, pam_env, and the various files source by shells like bash. It seems that systemd environment generators have been added due to #3904. Originally, the proposed solution using something in the PAM stack would have resulted in a consistent unique way to configure environment variables across all different kinds of sessions. However, due to valid security concerns that proposal has been modified and only the systemd user manager is aware of the environment configured via the environment generators.

In case of bug report: Expected behaviour you didn't see

I would have expected that environment variables configured by means of the user environment generator would be visible in all kinds of sessions. Currently, these environment variables are just visible to services started by the systemd user manager and gnome sessions, because gdm imports them.
What is the solution for sessions via console login and ssh-sessions. For the former one might be tempted to put a line like "export $(systemctl --user show-environment)" in a file like ~/.profile. This has two problems:

1. This is not read by ssh-sessions: Execution ssh localhost /usr/bin/env would miss the configured variables.
2. Putting the line also in ~/.profile of the HOME directory of root leads to strange results if one executes "su -".

The current situation is somewhat disappointing, as a unique reliable way of configuring environment variables does not exist.

[poettering]

well, very simply, i don't really see a way to implement that. there's no hook that would allow us to insert code right after the various programs that permit logins dropped privs, but before they invoke the user's $SHELL, or gnome-session or whatever else they need. There are specific hooks for various shells, but as you point out that doesn't really solve anything.

hence, i doubt there's anything we can do here...

[preinkemeier]

Hm. I kind of expected an answer like that. I just was not sure whether i understood the problem correctly, hence filed this report.
However i think the situation can at least be improved. An idea could be: If systemd would provide a single executable, which just executes the user environment generators according the logic documented in systemd's man pages and spits out the result to stdout, it would at least be possible to execute it from e.g. /etc/profile like "export $(path/to/that/file). This would already cover a lot of use-cases i think.
As i mentioned systemctl --user show-environment cannot be used in that case.

[preinkemeier]

Just a random thought: Wouldn't it be possible to implement the injection of the environment via some pam module, if that module would not parse the environment configuration files, but instead would drop priviledges like pam_env does and would talk to the systemd user manager, querying the user environment and setting it in the started session?
That was the the security related issues mentioned in the bug linked above would be gone. Is there anything obvious i am missing?

[james-lawrence]

system environment variables can be sensitive and should not be passed to the user logins.

it can also be done with a simple script in bashrc if this what the user whats:

export $(systemctl --user show-environment | xargs)

[preinkemeier]

I did not talk about system environment variables. I have suggested to pull in the environment variables stored in the systemd USER manager process, which the user has access to anyways. So there would not be any environment variables of the main systemd process passed to the user logins.

[zabbal]

What if there're no intermediary wrappers and the user's session is managed directly by "systemd --user"?
For example Gnome is doing that since 3.34 - https://blogs.gnome.org/benzea/2019/10/01/gnome-3-34-is-now-managed-using-systemd/
Does it mean that environment variables configured in ~/.config/environment.d/ can (already are?) be propagated to any shell spawned by the user automatically?

[nolange]

just ran into this issue aswell, even if no solution is possibly are there better workarounds than multiple per shell configuration files (assume I have bash and zsh)?
to make things worse, systemctl --user show-environment does not work for me as this requires dbus.

For serial-getty@.service I can manually set env variables, this could be made easier by allowing some "AppendUserEnvironment" key to the service (probably adds some risks adding user env variables to a system process)

For openssh I would not know.

[ljrk0]

system environment variables can be sensitive and should not be passed to the user logins.

it can also be done with a simple script in bashrc if this what the user whats:

export $(systemctl --user show-environment | xargs)

Another reason against this: If I'm logged in via a graphical session and now connect over SSH, I pull in things like XDG_CURRENT_DESKTOP which are arguably very false. The "best" thing I can see is to parse these files by hand within .profile which really isn't what I want to do...

Edit: Such a workaround has actually already been documented in the ArchLinux wiki: https://wiki.archlinux.org/index.php/Talk:Environment_variables#Consistently_setting_variables_across_systemd_units_&_regular_sessions

[abouvier]

Edit: Such a workaround has actually already been documented in the ArchLinux wiki: https://wiki.archlinux.org/index.php/Talk:Environment_variables#Consistently_setting_variables_across_systemd_units_&_regular_sessions

A generator already do the same:

export $(/usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator)

[ljrk0]

/usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator

Oh that's nice and I think a relatively workable solution that should cover the mentioned use-case, if I'm not missing something?

[bb010g]

Here's a more robust & POSIX-ly portable form of @abouvier's snippet:

set -a
. /dev/fd/0 <<EOF
$(/usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator)
EOF
set +a

[l3s2d]

With the pending pam_env user environment deprecation, can we revisit this? I asked on reddit [1], but it seems like there is no clear path forward for users wanting to set session environment variables in a DE/shell agnostic manner.

1. https://www.reddit.com/r/archlinux/comments/l0ascx/pam_env_is_being_deprecated_any_alternatives/

[l3s2d]

Arch Linux has just deprecated reading from ~/.pam_environment: https://bugs.archlinux.org/task/68945

There is some discussion of adding a source-able environment file here: #20914
This seems like an okay compromise, has there been any progress on this?