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
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
|
Details
Description:
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 expected. 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
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
FS#47884? /etc/profile no longer overwrites the existing $PATH...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.
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.
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
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.