Installing a .desktop file in /usr/share/wayland-sessions

[alan_g]

While experimenting with the proposed login-session-control interface I hit a snag with making a confined snap session available from the greeter:

How to install a .desktop file to /usr/share/wayland-sessions?

With classic confinement (as used by the egmde and plasma-desktop snaps) it is possible to copy a .desktop file to /usr/share/wayland-sessions in the install/configure hooks.

With strict confinement this is not possible:

error: cannot perform the following tasks:
- ... /usr/share/wayland-sessions/egmde-confined-desktop.desktop: Read-only file system)

This seems like something that should be handled by a snapcraft feature (like apps.<app-name>.desktop).

What does the team think?

[pedronis]

I probably don’t have enough context here, we do support .desktop files but those get sanitized and copied to /var/lib/snapd/desktop/applications/

[alan_g]

@pedronis, I know the .desktop extension is the same. But these .desktop files are not for use by the desktop shell, they are used by the greeter. They need to go in a different place. For example:

$ find /usr/share/wayland-sessions
/usr/share/wayland-sessions
/usr/share/wayland-sessions/gnome.desktop
/usr/share/wayland-sessions/egmde.desktop
/usr/share/wayland-sessions/ubuntu-wayland.desktop
/usr/share/wayland-sessions/miral.desktop
/usr/share/wayland-sessions/weston.desktop
/usr/share/wayland-sessions/ubuntu-communitheme-snap-wayland.desktop

[chipaca]

What use is a strictly-confined desktop shell, today? We don’t currently have a way for a strictly confined snap to launch a desktop app from a different snap.

[alan_g]

@chipaca

What use is a strictly-confined desktop shell, today? We don’t currently have a way for a strictly confined snap to launch a desktop app from a different snap.

True, a confined desktop is currently limited to running programs included in the snap and accepting connections from applications started elsewhere.

That doesn’t make it useful as a generic shell, but there are use cases for a confined environment with access to a selected applications. Last year I created a demonstration of this with egmde-confined-desktop.

Currently, that also needs root to access the hardware. But with my proposed login-session-control interface, I’ve a version of egmde-confined-desktop that can run without needing root. To add this to the greeter I’m creating /usr/share/wayland-sessions/egmde-confined-desktop.desktop “by hand” and am looking for the right way to automate this.

[pedronis]

That directory has wayland in its name, is the interface you are building specific to wayland? either way it seems like the interface itself would need to sanitize/copy the relevant files from the snap metadata to the relevant places when the interface is connected.

[chipaca]

FWIW I know other modern login managers do similar things, e.g. look in /usr/share/xsessions

[alan_g]

@pedronis

That directory has wayland in its name, is the interface you are building specific to wayland?

No, that’s just what I’m interested in. There’s also /usr/share/xsessions/.

Is there an example of an interface that something similar to what you suggest I can follow?

[pedronis]

Not really, you would probably need new dedicated backend, probably something you can discuss with @jdstrand.

[jdstrand]

First, a strict mode snap doesn’t have the ability to copy to /usr/share/anywhere because /usr comes from the base runtime, not the classic system.

Second, even if it could, @pedronis is right in that we would want some sort of snapd involvement to take the desktop file, sanitize it and put it in place. This doesn’t exist today and there isn’t anything for you to model your strict mode snap on to make it work today.

Third, a desktop shell is pretty specialized and we would want to think through at least the different pieces including login manager integration (this topic) and what you described in How to confine a desktop shell so we can come up with a decent solution.

OTOH, it does seem that login manager integration could be considered separately from the others… It definitely seems plausible to have some new yaml to declare one’s intent to integrate with the login manager. I think we would want that to be bound by snap declarations though, but I’m not sure a snapd interface is the correct fit (it feels more like the ‘autostart’ feature or even @jamesh session services work in that you want to register something to be startable, but otherwise don’t need any other accesses that aren’t covered by other (perhaps future) interfaces). Something along the lines of this:

apps:
  egmde:
    login-manager: egmde.desktop

is clean from a developer POV, but doesn’t integrate with our current concept of snap declarations so work would need to be done for that (ie, something like what we do for granting classic confinement is needed).

Introducing a new interface allows for using snap declarations immediately:

plugs:
  login-manager:
    interface: ???
    desktop: egmde.desktop
apps:
  egmde:
    plugs: [ login-manager ]

but seems slightly odd in that I don’t think there will be any other backends in use other than the login-manager backend (ie, the thing sanitizing the desktop files and putting them into place). Maybe that isn’t a bad thing…

Another option is doing something implied down in meta/login-manager/egmde.desktop, but this option makes it so we can’t regulate with a snap declaration.

Again, these are just ideas to help spark the conversation. Perhaps there are others or the ones above can be expanded to work best.

Considering the above, I think a good design is possible for how to expose this to snap developers, but the implementation may be complicated by directory placement across distros, the fact that xsessions/* and wayland-sessions/* have different content[1] and perhaps that different login managers need different support. Is /some/distro/path/wayland-sessions and /some/distro/path/xsessions a standard or a convention? Is the content of the *.desktop files a standard across all login managers that support the directories? How widespread is the support for these directories? Is it a Debian thing? A freedesktop.org standard?

There may be other things to consider (part of why I referenced @jamesh ) but hopefully this might help further the discussion.

[1] likely solvable with somewhere in the yaml:

...
    x-login-manager: egmde-x.desktop
    wayland-login-manager: egmde-wayland.desktop

[jamesh]

I don’t think this is really comparable to autostart or background user service features. This doesn’t augment the desktop session: instead it would offer another session option in the “gear” menu on the GDM login screen. Unless I’m missing something, explicit user action would be required to activate the new desktop session.

There is definitely room for confusion though. If you installed a new session with Name=Ubuntu in the .desktop file, it is not at all clear how you’d differentiate it from the real default session (other than the real one being selected by default).

[jdstrand]

@jamesh

I don’t think this is really comparable to autostart or background user service features. This doesn’t augment the desktop session: instead it would offer another session option in the “gear” menu on the GDM login screen. Unless I’m missing something, explicit user action would be required to activate the new desktop session.

You aren’t missing anything. I guess I wasn’t clear. I wasn’t saying it was comparable in terms of what it does, but that it is similar in that the feature would extend login manager capabilities on the system, outside of the snap, similar to how desktop autostart extends session autostarted services, outside of the snap. I was thinking through if such an extension is best expressed via an interface or not.

[jamesh]

I’m not sure how workable it would be to try and generate the session .desktop file purely from an interface plug/slot declaration. Like application .desktop files, they contain translatable strings that are displayed to the user.

I think the current handling of application desktop files is closer to the model that would be desired: validate a desktop file provided by the snap, and modify the Exec line to ensure the session is run with correct confinement.

[alan_g]

@jdstrand

How widespread is the support for these directories? Is it a Debian thing?

In practice, /usr/share/wayland-sessions works for Ubuntu and Fedora, and with sddm, gdm and lightdm but I’ve not found anything that gives me confidence that these locations are standardized.

[edit]

This isn’t fixed. https://www.systutorials.com/docs/linux/man/5-sddm.conf/ says:

[X11] section:
…
SessionDir=
Path of the directory containing session files. Default value is “/usr/share/xsessions”.
…
[Wayland] section:
…
SessionDir=
Path of the directory containing session files. Default value is “/usr/share/wayland-sessions”.

[jdstrand]

@jamesh

I’m not sure how workable it would be to try and generate the session .desktop file purely from an interface plug/slot declaration. Like application .desktop files, they contain translatable strings that are displayed to the user.

I think the current handling of application desktop files is closer to the model that would be desired: validate a desktop file provided by the snap, and modify the Exec line to ensure the session is run with correct confinement.

I guess I wasn’t clear on this point either: I was expressly not suggesting the definition coming solely from the yaml declaration, but rather the yaml declaration, whether interface or not, would point to a desktop file that would be sanitized (“we would want some sort of snapd involvement to take the desktop file, sanitize it and put it in place”). I was simply exploring where this is best expressed in the yaml.

[pedronis]

@jdstrand

OTOH, it does seem that login manager integration could be considered separately from the others… It definitely seems plausible to have some new yaml to declare one’s intent to integrate with the login manager. I think we would want that to be bound by snap declarations though, but I’m not sure a snapd interface is the correct fit

inventing something very specialized for this that is not an interface seems overkill, also I’m not sure why an interface would not fit, especially if we also think we want snap declaration control on this. There would be either a system slot (for classic only?), or a slot on snaps that can “host” sessions? those slots could also describe optionally where they want these .desktop files to go.