Commit 646b9bc0 authored by Iain Lane's avatar Iain Lane Committed by Ray Strode
Browse files

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.
parent abe22527
......@@ -35,6 +35,13 @@
static gchar *_saved_session_dir = NULL;
static gchar **child_environment;
static const char * const variable_blacklist[] = {
  • 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.


Please register or sign in to reply
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))
if (!g_utf8_validate (entry_name, -1, NULL))
......@@ -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))
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment