How to set global environment variables as a Linux distribution? - /etc/environment.d

Patrick · September 27, 2022, 8:05pm

How to set global environment variables as a Linux distribution?

Possibilities…

A) systemd /etc/environment.d might not be designed for that:

Pretty weird that systemd implemented /etc/environment.d in a way that is different from what would be expected similar to /etc/environment.

B) Perhaps systemd DefaultEnvironment=?

/etc/systemd/user.conf
- DefaultEnvironment=TESTVAR=xxx
- works for Qubes terminal emulator but fails for virtual console (dom0: sudo xl console vm-name).
/etc/systemd/system.conf
- DefaultEnvironment=TESTVAR=xxx
- works for
  - Qubes Debian terminal emulator and in virtual console
  - Debian terminal emulator and in virtual console
/usr/lib/systemd/system.conf.d/30_kicksecure.conf

[Manager]
DefaultEnvironment=TESTVAR=1

Works for Qubes terminal emulator and in virtual console.

C) Perhaps systemd Environment= for getty? (login shell)

D) Perhaps systemd EnvironmentFile= for getty? (login shell)

E) Debian /etc/environment.d but they didn’t like my feature request. That was probably pre systemd introducing their version of /etc/environment.d. Back then I failed to follow-up with use case examples for some reason as they requested to explain why this feature was requested.

Another attempt to for a feature request /etc/environment.d from Debian (now under a different folder since it’s already taken). Even if they reject it, they might suggest - ideally - an already existing better mechanism.

F) A feature request against PAM upstream, because quote:

The /etc/environment file is owned by pam.

Related discussions:

github.com/ayekat/localdir

Switch to environment.d for setting envvars

opened 01:53PM - 05 Nov 20 UTC

closed 08:31PM - 16 Apr 21 UTC

ayekat

Enhancement/Feature Fixed pam XDG systemd

With PAM developers having switched to setting `user_readenv` to 0 by default re…cently, and now with them voicing their intent to [remove `~/.pam_environment` entirely](https://github.com/linux-pam/linux-pam/issues/7#issuecomment-721595903), it's a good moment to seriously start thinking about moving variable declaration to environment.d. The downsides are: * environment.d reads from `$XDG_CONFIG_HOME/environment.d`, so there is a bit of a bootstrapping issue here: with pam_env disappearing, one can no longer define `$XDG_CONFIG_HOME` before environment.d runs (so it will either default to the specification-defined default (`~/.config`), or whatever the local sysadmin decides to set system-wide). We'll need a not-too-painful way of adapting to the individual cases; probably by symlinking `~/system-specific-xdg_config_home/environment.d` to `~/.local/etc/environment.d` as part of the initial dotfiles setup. * environment.d only applies to the systemd user daemon, but not the user *session*. So we will need a way to import variables into the login session as well. Either by `eval`ing the output of `systemctl show-environment`, or by reading the environment.d files directly (given that the `show-environment` output isn't POSIX conform, so we can't put that in `etc/sh/profile.d`). It's less than ideal, but as far as I can see, it's the only thing that is currently left for setting environment variables.

github.com/ayekat/localdir

Move variable declaration from pam_environment to environment.d

committed 06:49PM - 16 Apr 21 UTC

ayekat

+103 -42

Because environment.d only applies to the systemd user instance (but not the use…r session), we additionally need to process those files in the login shell now. In the long term, we may want to move more variables to environment.d (not just the ones for XDG). We still keep pam_environment around for declaring XDG_CONFIG_HOME (to solve the chicken-or-egg issue for systemd-environment-d-generator) and ZDOTDIR (to solve the chicken-or-egg issue for zsh). In cases where pam_env.so no longer loads ~/.pam_environment (either because of local configuration, or because of pam_env.so dropping support for that entirely), the work-around is to symlink ~/.config to ~/.local/lib/dotfiles/config (which then contains a single symlink for environment.d) and symlink ~/.zlogin to ~/.local/etc/zsh/.zlogin. An alternative would be to kindly ask the system administrator to set XDG_CONFIG_HOME and ZDOTDIR to desired values for my user (though I still have to find the most elegant way to achieve that).

https://www.reddit.com/r/zsh/comments/3ubrdr/proper_way_to_set_zdotdir/

Patrick · September 28, 2022, 11:12am

All packages shipped by Kicksecure / Whonix setting environment variables should deprecate their use of /etc/X11/Xsession.d and /etc/profile.d. Instead. the systemd DefaultEnvironment mechanism should be used.

This style:

Of course, split into different files and contained in the packages that require these.

/etc/X11/Xsession.d and /etc/profile.d mechanism:

Works in Debian (and Qubes Debian) in Xorg
Doesn’t work for virtual console with zsh.
Works with Wayland?
Works on non-systemd systems.
- Related: ⚓ T998 Whonix without systemD (Rejected.)
- Therefore not important since there are no ports / maintainers for non-systemd enabled systems anyway and also one on the horizon. Other init systems would need to support something similar to DefaultEnvironment.

systemd DefaultEnvironment mechanism:

Works in Debian (and Qubes Debian) in Xorg
Doesn’t work for virtual console with zsh.
Probably works with Wayland.
Only for systemd enabled Linux distributions.

nyxnor · September 28, 2022, 11:22am

Just to note, this is for Bourne shells, not Z shells (unless in compatibility mode)

Patrick · October 4, 2022, 4:48pm

As mentioned here:

systemd DefaultEnvironment mechanism doesn’t work with display manager lightdm for some reason.

Therefore porting all of Kicksecure / Whonix to systemd DefaultEnvironment mechanism is probably not a good idea until that is resolved and this being more tested in more environments.