`XDG_DATA_DIRS` is reset to a minimal list of directories in applications opened from the Qubes app menu, breaking default application resolution

[ArrayBolt3]

How to file a helpful issue

Qubes OS release

R4.3

Brief summary

Whonix modifies the XDG_DATA_DIRS environment variable via scripts in /etc/profile.d (and /etc/zprofile.d). These modifications allow Whonix to customize things such as default application associations. These changes are picked up by Qubes OS and do appear in login shells, but somehow XDG_DATA_DIRS (and to my awareness, only XDG_DATA_DIRS) is reset to a "minimal" set of directories in applications that are opened from the Qubes app menu. This results in all of Whonix's file association settings usually being ignored.

Steps to reproduce

• Install a Whonix-Workstation 18 template.
• Create an AppVM based off this template, and launch QTerminal in it.
• Run echo $XDG_DATA_DIRS.
• Open Qube Manager, select the Whonix-Workstation 18 AppVM, and click "Open console in qube".
• Log in as "user" (no password required), then run echo $XDG_DATA_DIRS.

Expected behavior

In both instances, echo $XDG_DATA_DIRS should output /usr/share/usability-misc/xdg-override/:/usr/share/anon-apps-config/share/:/usr/share/open-link-confirmation/xdg-override:/var/lib/flatpak/exports/share:/usr/local/share/:/usr/share/ or similar.

Actual behavior

In the DispVM console, echo $XDG_DATA_DIRS outputs the expected value, but in QTerminal, the returned string is /home/user/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share/:/usr/share/.

Additional information

This is contributing to an issue, where clicking on the Qubes Domains widget in the system tray, hovering over a Whonix-Workstation 18 qube, and clicking "Open File Manager" opens Catfish File Search rather than PCManFM-Qt. Whonix ships a file at /usr/share/usability-misc/xdg-override/applications/defaults.list that is supposed to set the default application for inode/directory to pcmanfm-qt.desktop. Right now that file is out-of-date and is pointing to thunar.desktop instead, but even when it is changed to point to pcmanfm-qt.desktop, Catfish still opens when clicking this button in the widget. Running xdg-open $HOME in QTerminal also opens Catfish. However, running DISPLAY=:0 xdg-open $HOME in the DispVM console opens PCManFM-Qt as expected. (Granted, it looks awful because QT_QPA_PLATFORMTHEME='lxqt' is strangely not being set properly, but that's an unrelated issue.)

The only thing I see in Qubes' code that looks like it modifies XDG_DATA_DIRS is https://github.com/QubesOS/qubes-core-agent-linux/blob/bffc6e0d0df3874781c0feda8297be5063fabba1/qubes-rpc/qubes.StartApp. Could this be part of the issue?

[ArrayBolt3]

The only thing I see in Qubes' code that looks like it modifies XDG_DATA_DIRS is https://github.com/QubesOS/qubes-core-agent-linux/blob/bffc6e0d0df3874781c0feda8297be5063fabba1/qubes-rpc/qubes.StartApp. Could this be part of the issue?

Scratch that, most likely a red herring. XDG_DATA_DIRS is only modified when force_open_dvm is True.

[ArrayBolt3]

The plot thickens... if opening QTerminal in Whonix-Workstation 18 using qvm-run -u root anon-whonix qterminal, XDG_DATA_DIRS is properly set. If running it via qvm-run -u user anon-whonix qterminal or simply qvm-run anon-whonix qterminal, XDG_DATA_DIRS is improperly set. Is something stripping it from user sessions?

[ArrayBolt3]

Finally reproduced this in a vanilla Debian 13 template. The culprit appears to be Flatpak - if I sudo apt install flatpak, XDG_DATA_DIRS gets reset as described above. Removing it causes the resetting to stop happening.

The reset also seems to happen if and only if a terminal is opened as whatever the default user is. Starting a terminal as a non-default user results in the command line being set properly in that terminal.

[ArrayBolt3]

After much more fighting with the system, I think I've figured out most of the issue. For some reason environment variables generated by /usr/lib/systemd/system-environment-generators and /usr/lib/systemd/user-environment-generators are taking precedence over variables defined in /etc/profile.d. Thus even though XDG_DATA_DIRS is set properly in /etc/profile.d, it gets clobbered by the environment generators. /usr/lib/systemd/user-environment-generators/60-flatpak runs flatpak --print-updated-env, which appears to be designed to augment an already-set XDG_DATA_DIRS variable (i.e. if XDG_DATA_DIRS already has special additional directories configured in it, this command outputs an XDG_DATA_DIRS variable that includes those extra directories), so my current guess is that on "normal" systems, /etc/profile.d's variables are being loaded before the environment generators run, but on Qubes OS the environment generators run first.

[ArrayBolt3]

I think I found the issue: https://github.com/QubesOS/qubes-gui-agent-linux/blob/b1c52ac515556e3bb02c712d60d7105d5b98b994/appvm-scripts/usrbin/qubes-session#L36

We start the X11 session with a login shell in https://github.com/QubesOS/qubes-gui-agent-linux/blob/b1c52ac515556e3bb02c712d60d7105d5b98b994/appvm-scripts/usrbin/qubes-run-xorg#L102, which loads all of the environment variables from /etc/profile.d. Then that calls qubes-session, which proceeds to overwrite parts of that environment with whatever is present in systemctl --user show-environment, which doesn't know about any variables that have been set in /etc/profile.d and thus contains an XDG_DATA_DIRS variable lacking any of the added directories from /etc/profile.d. That's how XDG_DATA_DIRS gets clobbered.

Adding a dbus-update-activation-environment --systemd --all call immediately before importing the environment from systemctl --user show-environment appears to resolve the issue.