Bug#1037084: bookworm: When using gdm3 to start non-GNOME wayland sessions, PATH may be set differently

[Jay]

Package: release-notes
X-Debbugs-Cc: ***@protonmail.com
Severity: important

Starting non-GNOME wayland sessions through GDM leads to a user's PATH
being set to
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
instead of /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
(from /etc/profile).

Example: Starting sway or plasma-workspace-wayland through gdm and
trying to launch
lutris or gnome-chess only to find out that they won't start even
though they are
installed. It can take some time for a user to find out that the PATH
environment
variable is different.

This is a regression in bookworm and can surprise users upgrading from bullseye.

Possible workarounds are: Using a different display manager such as
sddm or starting
the wayland session through tty.

I first discovered this bug after installing lutris a few months
ago[0] and filed
a few bug reports[1][2]. As bookworm is about to be released, I thought it may
be worthwhile to document this unexpected behavior in its release notes.

0: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028543
1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942131
2: https://gitlab.gnome.org/GNOME/gdm/-/issues/846

[Alban Browaeys]

GDM imports system user environment variables.
This bug would likely be fixed by Debian (the systemd package?)
shipping a /usr/lib/systemd/user-environment-generators/ systemd user
environment generator with the default PATH Debian already set in
/etc/profile.
gnome-session importing /etc/profile is a temporary hack, so even for a
plain Gnome session this will not work forever without this fix.

Or ship an /usr/lib/environment.d/*.conf file (which itself is read by
a systemd user environment generator : /usr/lib/systemd/user-
environment-generators/30-systemd-environment-d-generator).

Cheers,
Alban

Post by Jay
Package: release-notes
Severity: important
Starting non-GNOME wayland sessions through GDM leads to a user's PATH
being set to
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
instead of /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
(from /etc/profile).
Example: Starting sway or plasma-workspace-wayland through gdm and
trying to launch
lutris or gnome-chess only to find out that they won't start even
though they are
installed. It can take some time for a user to find out that the PATH
environment
variable is different.
This is a regression in bookworm and can surprise users upgrading from bullseye.
Possible workarounds are: Using a different display manager such as
sddm or starting
the wayland session through tty.
I first discovered this bug after installing lutris a few months
ago[0] and filed
a few bug reports[1][2]. As bookworm is about to be released, I thought it may
be worthwhile to document this unexpected behavior in its release notes.
0: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028543
1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942131
2: https://gitlab.gnome.org/GNOME/gdm/-/issues/846

[Jay]

Post by Alban Browaeys
This bug would likely be fixed by Debian (the systemd package?)
shipping a /usr/lib/systemd/user-environment-generators/ systemd user
environment generator with the default PATH Debian already set in
/etc/profile.

I plan to check with the Debian systemd package maintainers about this option.

But

Post by Alban Browaeys
Or ship an /usr/lib/environment.d/*.conf file (which itself is read by
a systemd user environment generator : /usr/lib/systemd/user-
environment-generators/30-systemd-environment-d-generator).

This might be the solution we're looking for. A
/usr/lib/environment.d/??-gdm3.conf file
provided by the gdm3 package?

[Alban Browaeys]

On Sat, Jun 17, 2023 at 4:55 AM Alban Browaeys

Post by Alban Browaeys
This bug would likely be fixed by Debian (the systemd package?)
shipping a /usr/lib/systemd/user-environment-generators/ systemd user
environment generator with the default PATH Debian already set in
/etc/profile.

I plan to check with the Debian systemd package maintainers about this option.
But

Post by Alban Browaeys
Or ship an  /usr/lib/environment.d/*.conf file (which itself is

read by

Post by Alban Browaeys
a systemd user environment generator : /usr/lib/systemd/user-
environment-generators/30-systemd-environment-d-generator).

This might be the solution we're looking for. A
/usr/lib/environment.d/??-gdm3.conf file
provided by the gdm3 package?

No, in that it should not be named after gdm.
It is a bit far, but to me your issue is due to gdm3 not overwriting
the systemd user environment with its own PATH value anymore. This
means that you got things back working by reverting
https://gitlab.gnome.org/GNOME/gdm/-/commit/ccecd9c975d04da80db4cd547b67a1a94fa83292
because you made gdm3 overwrite the system user session environment
PATH value as it was doing before.
So the issue is that the systemd user enviroment is not set properly
for Debian specific PATH components (and that gdm3 does not overwrite
this systemd user session PATH value anymore if one is set, thus the
gdm3 fallback PATH mention in the patch. That is if no PATH value is
defined in the environment, then the old behavior of gdm setting it is
preserved, but if one is defined, then it is not changed).
Thus if you get the wrong PATH value it is not because gdm set it to
the wrong value, but because it stopped overweriting the bad value (in
that Debian requires a specific value that is not hte default and as no
Debian specific config has been provided, the default is wrong).


So the issue is, to me, Debian systemd specific and only involves gdm
because it has stopped overwriting the systemd default value (which is
wrong on Debian because Debian has specific path).

The Debian specific defaults are shown in /etc/profile
if [ "$(id -u)" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi
export PATH


Debian systemd package just need to ship a config file to set this PATH
value.
So a /usr/lib/environment.d/??-debian.conf file shipped by the Debian
systemd package is what I deem the correct fix.

This bug report should be reassigned to systemd in my opinion.


So you were right that reverting commit ccecd9c9 would fix your issue,
but not because gdm added a bug but because it stopped hiding an
underlying "bug" (well wrong default PATH value in systemd for Debian).
It could be that systemd maintainers thing this is gdm job to overwrite
their value, though it looks more correct to me to bug them first as
they are the one setting the wrong default for Debian (or so I believe,
I have not checked extensively if the wrong PATH default value could be
fine at the systemd level and be changed afterwards).

Cheers,
Alban