Bug#1051010: lwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

[Simon McVittie]

Package: lwm
Version: 1.2.4-1
Severity: normal
User: xdg-deskt...@packages.debian.org
Usertags: portals.conf

As well as being available as a window manager to integrate into some
larger environment, Lwm behaves like a very small desktop environment
in its own right, by providing a /usr/share/xsessions/lwm.desktop
which can be selected on entry to a display manager such as lightdm.
If it's going to register as a desktop environment, then it should behave
like a desktop environment in other ways, such as choosing an
XDG_CURRENT_DESKTOP identifier.

xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:

- each desktop environment should provide a file like
/usr/share/xdg-desktop-portal/lwm-portals.conf

- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case

- sysadmins and users can override this via files named portals.conf or
${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
and ~/.config/xdg-desktop-portal

But as far as I can tell, Lwm doesn't set XDG_CURRENT_DESKTOP, so for
the purposes of this mechanism, it's not programmatically distinguishable
from any other desktop environment or window manager.

XDG_CURRENT_DESKTOP is also used in pre-existing freedesktop.org standards
like the OnlyShowIn/NotShowIn fields for .desktop files, and the ability to
provide a desktop-environment-specific mimeapps.list. Setting
XDG_CURRENT_DESKTOP would allow Lwm to participate in those
specifications.

To reproduce
============

* Start from a basic non-GUI virtual machine (I used autopkgtest-build-qemu)
* Ensure that a user account exists
* apt install lightdm xorg lwm
* reboot
* Log in as the user account, selecting "Lwm" from the menu of
possible X11 sessions
* Open an xterm and run:
systemctl --user show-environment

(It's the systemd activation environment that matters here, more than
`env`, because xdg-desktop-portal will typically be run as a systemd
user service.)

Expected result
===============

XDG_CURRENT_DESKTOP should be set to a colon-separated sequence of
desktop environment names, most specific first. Lwm seems to be its
own thing rather than being based on another desktop environment, so

XDG_CURRENT_DESKTOP=Lwm

would seem appropriate.

This would allow the Lwm session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/lwm-portals.conf.

Actual result
=============

XDG_CURRENT_DESKTOP is unset.

This means that xdg-desktop-portal configuration can only be done via a
non-desktop-specific portals.conf, but that's not really something that a
non-opinionated distribution like Debian can usefully ship in a centralized
way, so each user of Lwm who wants a working xdg-desktop-portal will
have to configure it themselves.

At the moment, this is mitigated by xdg-desktop-portal (>= 1.17) having
been patched to fall back to xdg-desktop-portal-gtk as a last-resort
desktop-environment-specific backend, but hard-coding that implementation
isn't really something we should be doing centrally (and the idea was
rejected upstream), so I intend to remove that patch before trixie
is released.

Suggested fix
=============

Add a sequence of semicolon-separated desktop environment names to
/usr/share/xsessions/lwm.desktop, most likely just "Lwm":

DesktopNames=Lwm;

(For example, icewm and windowmaker use "ICEWM" and "WindowMaker" in
their equivalent xsessions file.)

And then create a /usr/share/xdg-desktop-portal/lwm-portals.conf
with whatever portal backends are desired for an Lwm session,
for example perhaps this:

[preferred]
default=gtk;

Please see portals.conf(5) or its source code
https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
for full details.

Thanks,
smcv

--
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html

[Nicholas Bamber]

So far in order to investigate I have:

1. installed discord on a lwm desktop via flatpak. This works but is
pretty ugly and the whole filesystem is exposed.

2. Looking into ways to get the XDG_CURRENT_DESKTOP into the systemd
user environment.

Putting a script into the 55 priority in /etc/X11/Xsession.d. This works
(and does not pollute other desktop environments since we can check at
that point). However it depends on the the package dbus-x11 and I have
concerns about the long term support for this package.

Looking at bug #943917, I see these concerns over the dbus-x11 package
and  a suggestion that environment.d be used. However this is
unacceptable because that will load the environment variables
irrespective of what desktop environment is chosen. Specifically I have
tested it shows up in "systemctl --user show-environment" but does not
show up in "env" when you login to an openbox desktop.


So the Xsession.d approach seems to be the way to go, but I also have
concerns about how many dependencies (even at the suggests level) should
be added to a package intended to be lightweight. Obviously this could
all be documented.

[Simon McVittie]

I've changed the subject line back to the one from the bug - I get a
*lot* of bugmail, which I usually see out-of-context, so "Investigating"
doesn't really work as a reminder of what bug and what package you're
talking about. I hope that's compatible with your workflow.

On Fri, 02 Feb 2024 at 12:11:13 +0000, Nicholas Bamber wrote:
> So far in order to investigate I have:
>
> 1. installed discord on a lwm desktop via flatpak. This works but is pretty
> ugly and the whole filesystem is exposed.

Large proprietary apps containing an entire web browser engine tend not to
be feasible to sandbox meaningfully, unfortunately, especially if their
packagers want them to have full functionality for users who are unaware of
the existence of sandboxing and want everything to "just work".

My usual go-to test apps are GNOME Recipes
https://flathub.org/apps/org.gnome.Recipes, ASHPD demo
https://flathub.org/apps/com.belmoussaoui.ashpd.demo, or the portal tests
built by src:libportal (install libportal-tests-gtk3 and
libportal-tests-gtk4 and run with "GTK_USE_PORTAL=1 GDK_DEBUG=portals" in
the environment, or you can build them into Flatpak apps from the source
package). Those are a lot more meaningfully sandboxed.

> 2. Looking into ways to get the XDG_CURRENT_DESKTOP into the systemd user
> environment.

In the original bug report, part of the solution I suggested was this:

Add a sequence of semicolon-separated desktop environment names to
/usr/share/xsessions/lwm.desktop, most likely just "Lwm":

DesktopNames=Lwm;

(For example, icewm and windowmaker use "ICEWM" and "WindowMaker" in
their equivalent xsessions file.)

Most display managers take this into account and will convert it into
setting the XDG_CURRENT_DESKTOP setting (for example, I know that gdm3,
lightdm and sddm do this).

This won't work for xdm, but at some point I think we have to start
treating that sort of thing as an xdm limitation, rather than something
that individual desktop environments are expected to address?

> Putting a script into the 55 priority in /etc/X11/Xsession.d. This works
> (and does not pollute other desktop environments since we can check at that
> point). However it depends on the the package dbus-x11 and I have concerns
> about the long term support for this package.

Doesn't the combination of these two files

dbus-user-session: /etc/X11/Xsession.d/20dbus_xdg-runtime
dbus-x11: /etc/X11/Xsession.d/95dbus_update-activation-env

already do what's needed here? Those two packages represent the only two
implementations of the dbus-session-bus virtual package that currently
exist in Debian.

xdg-desktop-portal already depends on
default-dbus-session-bus | dbus-session-bus, so whenever xdg-desktop-portal
is installed, so is at least one of those two packages; and they both pull
in dbus-bin, which provides /usr/bin/dbus-update-activation-environment.

If someone adds a third implementation of dbus-session-bus, I think it
would be entirely reasonable for us to expect it to have similar handling
of at least the most basic variables like DBUS_SESSION_BUS_ADDRESS,
DISPLAY, XAUTHORITY and XDG_CURRENT_DESKTOP.

The other possible way to do this, which *would* work even for xdm, is to
do like gnome-session does, and upload at least those few basic environment
variables to the D-Bus activation environment during GUI session startup,
either from the main executable (using libdbus or a similar library) or
from a shell script wrapper (using dbus-update-activation-environment or
equivalent). This wouldn't necessarily have to imply a hard dependency
on d-u-a-e, it could be done conditionally. I realise that this is
unappealing for a specifically lightweight desktop environment, so I'd
be fine with the answer to this particular part being "wontfix, use a
better display manager if you want this functionality".

smcv

[Nicholas Bamber]

Simon,

Thanks for the hints. I will explore them.

(and sorry about the email title.)


Nicholas

[Nicholas Bamber]

Firstly by copying, pasting and editing the xsessions desktop file from icewm to lwm I have been able to get XDG_CURRENT_DESKTOP=lwm into systemd, without any other files. I can see that this is the cleanest method. That said I infer from what I saw that every display manager is doing its own thing here and that is surely less than ideal.

I have played a bit with setting up lwm-portals.conf but at the moment I more interested in trying to see if I can lock it down than write something I would expect to be in a default Debian config. I found the man page for portals.conf a bit confusing here. I have put the file in /usr/share/xdg-desktop-portal/lwm-portals.conf but there also seem to be implementation files in /usr/share/xdg-desktop-portal/portals and I find that a bit confusing.

Secondly I saw a youtube video saying that discord totally ignores sandboxing so I won't be using that for testing. I have played about with GNOME recipes and  ASHPD demo and I am still not seeing much difference. From what I can see they are just following UNIX permissions with no additional sandboxing.

or the portal tests
built by src:libportal (install libportal-tests-gtk3 and
libportal-tests-gtk4 and run with "GTK_USE_PORTAL=1 GDK_DEBUG=portals" in
the environment, or you can build them into Flatpak apps from the source
package). Those are a lot more meaningfully sandboxed.

I am still trying to understand what is being suggested here. Working on it. I can say that if I try to build xdg-desktop-portal I get some test failures:

 9/28 xdg-desktop-portal:portals / test-portals-location      ERROR           26.28s   killed by signal 6 SIGABRT^M
12/28 xdg-desktop-portal:portals / test-portals-openuri       TIMEOUT         30.01s   9 subtests passed

but I don't think I had read the suggestion correctly when I tried this.