FS#56716 - [filesystem]: Export variables set via */environment.d/*.conf files

Attached to Project: Arch Linux
Opened by Philipp Reinkemeier (philipp.reinkemeieroffis.de) - Thursday, 14 December 2017, 10:24 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:23 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Sébastien Luttringer (seblu)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No


filesystem provides /etc/profile setting environment variables.
Recently, systemd got a new feature for configuring environment
variables via */environment.d/*.conf files. Environment variables
configured via these files end up in the environment block of
the systemd user manager. Thus, every service executed by it
is aware of them. However, up to now, these environment variables
do not necessarily end up in login sessions. For instance if
one logs in via the console or ssh, these environment variables
are not set. On the other hand gnome seems to import them
along with also executing a login shell, thus reading /etc/profile.
This leads to the problem mentioned in
https://github.com/systemd/systemd/issues/6414: The environment
variable PATH, if configured via e.g. some file in ~/.config/environment.d/
is overwritten, because /etc/profile is executed as well. On
the other hand an environment variable PATH1 would have a value as

This feature request is about to make sure that environment variables
have consistent values, independently of whether one logs in via the
console or some graphical session.
A way to achieve this would be to add the following line to /etc/profile
right after the execution of scripts in /etc/profile.d/:

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

A user can then configure environment variables either via the logic provided
by systemd or via ~/.profile. Further, this opens up the possibility to smoothly
migrate some scripts in /etc/profile.d to the systemd-logic of setting environment
variables. Examples of such scripts are "jre.sh", "libreoffice-*.sh", "locale.sh",
"mozilla.sh", ...
Thus, environment variables seen by services executed by the systemd user manager
process would get consistent with the ones seen in login sessions.

Additional info:
* filesystem 2017.10-2

Steps to reproduce:
1. Create a file ~/.config/environment.d/10-path.conf with
the following content PATH=foo${PATH:+:$PATH}
and PATH1=foo${PATH:+:$PATH}
2. Log into gnome and execute env in a terminal.
One gets PATH=X and PATH1=foo:X.
3. Login via getty and execute env.
One gets PATH=X and PATH1 is not defined.
Expected would be PATH=foo:X and PATH1=foo:X in
both cases.
This task depends upon

Closed by  Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:23 GMT
Reason for closing:  Moved
Additional comments about closing:  https://gitlab.archlinux.org/archlinux/p ackaging/packages/filesystem/issues/4
Comment by Eli Schwartz (eschwartz) - Monday, 25 December 2017, 21:07 GMT
Is this still a problem after  FS#47884 ? /etc/profile no longer overwrites the existing $PATH...
Comment by Sébastien Luttringer (seblu) - Monday, 25 December 2017, 21:13 GMT
This looks like a feature request, not a bug/problem.
Comment by Eli Schwartz (eschwartz) - Monday, 25 December 2017, 21:19 GMT
"The environment variable PATH, if configured via e.g. some file in ~/.config/environment.d/ is overwritten, because /etc/profile is executed as well." --> no longer should happen, I believe.

Shouldn't user sessions already be loading this or something anyway? I mean, that kind of looks like what an environment.d generator would be supposed to do in the first place.
Comment by Philipp Reinkemeier (philipp.reinkemeieroffis.de) - Friday, 29 December 2017, 19:27 GMT
@Eli Schwartz: "Is this a problem after  FS#47884  ? /etc/profile no longer overwrites the existing $PATH"

Yes and no:

No, because probably PATH is no longer overwritten (i did not test it, but the solution in https://bugs.archlinux.org/task/47884
looks good iff there's no other place where PATH is not extended but set to a fixed value).

Yes, because there is a discrepancy in environment variables picked up by different sessions e.g. gnome and login and ssh. The problem is that gnome picks up the configurations done in e.g. ~/.config/environment.d/ and ~/.profile, while logging in via the console (ultimately executing login, which executes the shell specified in /etc/passwd) does NOT consider ~/.config/environment.d/ in any way, but executes ~/.profile. This feature request is mainly about making environment variable configurations more consistent across different session types ("more" because currently there does not seem to be a way to enforce application of environment variable configurations in all different types of login sessions in a secure way as discussed upstream https://github.com/systemd/systemd/pull/3904).
Currently the user can only use ~/.profile to set environment variables consistently for at least console and gnome sessions. Implementing the proposal above should make it possible for the user to choose whether he/she wants to use ~/.profile or ~/.config/environment.d/, both would work.
Comment by Sébastien Luttringer (seblu) - Tuesday, 21 May 2019, 15:23 GMT
Looks like upstream is well aware[1] that these user-env-generators doesn't provide a solution for having the same environment when login between desktop/login/ssh.

We could eventually improve the situation by loading them into our profile shell. This require to load all user generators and not only 30-systemd-environment-d-generator.

[1] https://github.com/systemd/systemd/pull/5131#issuecomment-281297504
Comment by marc boocha (marcthe12) - Friday, 11 September 2020, 12:44 GMT
I have snip bit in my /etc/profile:
set -a
eval "$(systemctl --user show-environment)"
set +a

The big problem here is to prevent code injection by systemctl --user show-environment. Also upstream gnome wayland does not even read /etc/profile anymore and directly gets it from the dbus call which is equillant to this function.
Comment by Buggy McBugFace (bugbot) - Tuesday, 08 August 2023, 19:11 GMT
This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.