New interfaces needed for plasma-desktop-session

store-requests privileged-interfaces
1

Hello,

As requested by @jslarraz this is a separate request to add a few interfaces as auto-connect and adjust one on the plasma-desktop-session package.

This has been already a been discussed with @cav here:

  • name: plasma-desktop-session
  • description: Snap wrapping a full fledged KDE Plasma session (binaries provided by plasma-core24-desktop content snap)
  • snapcraft: https://invent.kde.org/neon/snap-packaging/plasma-desktop-session/-/blob/master/snap/snapcraft.yaml
  • upstream: N/A
  • upstream-relation: N/A
  • interfaces:
    • systemd-user-control:
      • request-type: auto-connection
      • reasoning: the desktop session needs to talk to systemd to orchestrate the startup
    • pipewire:
      • request-type: auto-connection
      • reasoning: the desktop session needs to talk to Pipewire for the screen sharing
    • shutdown:
      • request-type: auto-connection
      • reasoning: to be able to trigger shutdown from the application menu of the session
    • system-files (shell-config-files):
      • request-type: auto-connection
      • reasoning: this is not a new interface to add, but it has been adjusted to also include /etc/security in addition to /etc/pam.d (the latter was enough in core22, but core24 pushed us to add this extra directory)
2

This request has been added to the queue for review by the @reviewers team.

3

hi @kottens - sorry for the delay!

+1 for auto-connecting pipewire, shutdown and shell-config-files (updates) given the discussion above and the previous thread.

For now we can continue to manually approve systemd-user-control until the interface is apart of reviewtools

4

Thanks! We need another vote at least beyond @cav I guess?

Sorry to bother but any chance to speed this up a bit? I’d like to be able to finally test the new iteration with all the blocks assembled straight from the store.

5

+1 for granting auto-connection to the requested interfaces, as I think those makes sense for a desktop session snap.

However, we cannot grant auto-connection to pipewire as of now and it will only be done after landing the new review-tools revision.

Also publisher vetting is needed for the shutdown interface. However, the snap is publisher under the kde verified account so we can go ahead

Could you please request manual review for you last revision in the store?

6

@jslarraz Thanks! I understand pipewire is under the same regime than systemd-user-control for now. Makes sense. Expect me to ask again on further revision of the package though.

I requested the manual review in the store now.

7

I’ve granted auto-connection to shutdown interface and requested personal-files and system-files. This is now live

Could you please request manual review just once again so I can manually approve it?

Thanks

8

Just did it now.

Thanks.

9

It is now approved. Please let me know if everything works as expected

10

Looks like the systemd-user-control auto-connection is missing? I’m getting this when I try to install the package from the store: installation not allowed by "systemd-user-control" plug rule of interface "systemd-user-control".

11

hi @kottens

I just tried installing the snap and it seemed to be successful. Does this issue still occur on your end?

$ snap install plasma-desktop-session --edge
2025-04-01T10:17:53+10:00 INFO snap "plasma-desktop-session" has bad plugs or slots: pipewire (unknown interface "pipewire"); systemd-user-control (unknown interface
"systemd-user-control")
2025-04-01T10:18:04+10:00 INFO snap "plasma-desktop-session" has bad plugs or slots: pipewire (unknown interface "pipewire"); systemd-user-control (unknown interface
"systemd-user-control")
plasma-desktop-session (edge) 20250319+gitb1c8cc7 from KDEâś“ installed
WARNING: There is 1 new warning. See 'snap warnings'.
12

Hello @cav

Still the same here. I’m trying on an Ubuntu Core system though, is it the case on your end as well? It could make a difference IMO.

13

Hi again @cav

Actually I think it’s because you’re testing with a regular snapd but we have a fork on Core Desktop for now which knows the systemd-user-control and pipewire interfaces. In the case of systemd-user-control it’s by default not allowing installation, I think it needs to be overridden from the store assertion.

IIRC you did that in the past but it didn’t happen this time around.

Thanks in advance.

14

hi @kottens

oh true. in that case, is the version of snapd used on core desktop locally patched with the systemd-user-control override?

15

Hello @cav

The snapd used on core desktop provides the systemd-user-control interface, but is declared with allow-installation: false on the plug declaration side. It’s been like this for the past few months.

16

hi @kottens - we plan to discuss this within the review team in the next day or two and will get back to you with how to get this sorted!

17

This has happened a few times with various snaps: a request is made for an addition to the snap declaration, and another part of the declaration is removed without discussion. It can be incredibly disruptive, since assertion updates propagate very quickly and affect all users of the snap.

Is there any process in place to make sure that only the requested changes are made to the snap declaration?

18

Hey folks

a request is made for an addition to the snap declaration, and another part of the declaration is removed without discussion.

Whilst you are right and that has happened few times, I don’t think it is the case this time. Looking at the declaration history and review-tools output for past revisions I think systemd-user-control has never been granted. That makes sense as this interface is not known to review-tools.

After discussion with @pedronis, it seems that this interface won’t ever be added to the “oficial” snapd project. Thus, I don’t think we should add support for it in review-tools.

Considering that you are using a fork of snapd, I think that a more appropriate solution (just for testing purposes until the long-term solution would be available in snapd) would be to update the base declaration for the systemd-user-control on your fork, so no assertion from the store would be needed.

Is there any process in place to make sure that only the requested changes are made to the snap declaration?

I’m not aware of any plan in that direction. However, I imagine that it should be implemented by the store team in the dashboard

19

Looking at the declaration history and review-tools output for past revisions I think systemd-user-control has never been granted.

I’m pretty sure it has been granted, @cav did it by hand a couple of times on previous iterations of the same package. It was also installed just fine, in the meantime the base declaration in the snapd fork didn’t change.

20

Hey,

  • I just looked again to the declaration history and I could not find any evidence that it is was granted.
  • If for some reason an unexpected interface name is found the declaration (as it would be the case for systemd-user-control) automatic review immediately exits with the Unexpected output from snap-review. snap-review. I see it is not the case for any of the snap revisions.
  • Finally, according to @cav comment in the original thread, it seems that the suggested solution was also to update the base declaration on your side. Commentaries in the original topic suggest that @cav only manually approved the revision (in the same way I did for the latest one) and I could not find any commentary that indicates that the declaration was granted in the store side at all

I might be missing something, but everything points out that it was never granted tbh.