util: Blacklist some session-specific variables

Things like XDG_SESSION_ID should not be uploaded to the environment.
For example this is broken currently:

  1. SSH to your machine
  2. Log in to GNOME Shell
  3. Log out
  4. Log in again
  5. Lock the screen
  6. Try to unlock

You can't, and this is because the XDG_SESSION_ID from the first session
(step 2) has leaked through to the second one (step 4), and so GNOME
Shell is listening to the `logind` `UnlockSession` signal for the wrong
session. The SSH session established in step 1 serves to keep the
`systemd --user` instance alive, so that the state is not torn down
between logins.

gnome-session/gsm-util.c

@@ -35,6 +35,13 @@
 static gchar *_saved_session_dir = NULL;
 static gchar **child_environment;
 
+static const char * const variable_blacklist[] = {
+    "XDG_SEAT",
+    "XDG_SESSION_ID",
+    "XDG_VTNR",
+    NULL
+};
+
 char *
 gsm_util_find_desktop_file_for_app_name (const char *name,
                                          gboolean    look_in_saved_session,
@@ -532,6 +539,9 @@ gsm_util_export_activation_environment (GError     **error)
                 const char *entry_name = entry_names[i];
                 const char *entry_value = g_getenv (entry_name);
 
+                if (g_strv_contains (variable_blacklist, entry_name))
+                    continue;
+
                 if (!g_utf8_validate (entry_name, -1, NULL))
                     continue;
 
@@ -603,8 +613,13 @@ gsm_util_export_user_environment (GError     **error)
                 return FALSE;
         }
 
+        entries = g_get_environ ();
+
+        for (; variable_blacklist[i] != NULL; i++)
+                entries = g_environ_unsetenv (entries, variable_blacklist[i]);
+
         g_variant_builder_init (&builder, G_VARIANT_TYPE ("as"));
-        for (entries = g_get_environ (); entries[i] != NULL; i++) {
+        for (i = 0; entries[i] != NULL; i++) {
                 const char *entry = entries[i];
 
                 if (!g_utf8_validate (entry, -1, NULL))

[Samuel Thibault]

Hello,

This broke the Braille output of Orca. Orca needs the XDG_VTNR variable in order to get the Braille output correctly. The correction actually looks wrong to me: these XDG variables do make sense inside the session. The real bug here would rather be the leak from one gnome session to another, i.e. the fact that the variable gets somehow stored inside the user systemd session.

In the current code state, there is an additional NOTIFY_SOCKET variable which is said not to be ever passed to the gnome session, so the code should be kept at least for that variable. But for the others I don't see why blacklisting them entirely. The current code state says "they might end up in the wrong session". The scenario of the changelog of this commit would be an example of this, but is that leak unfixable at its root rather than here? Actually, I tried to reproduce the scenario on Debian bullseye updated today, and the bug didn't happen. My ssh connection got XDG_SESSION_ID 7, my wayland session then got XDG_SESSION_ID 8, and after unlog/relog, my wayland session got XDG_SESSION_ID 10 (I guess gdm itself has a session). Yes, my ssh session was still active.

So I would say that the leak bug is actually gone and these XDG_SEAT, XDG_SESSION_ID and XDG_VTNR don't need to be blacklisted any more, and doing so would fix the Orca Braille output.

I have submitted !43 (closed) to restore letting them pass.

Samuel