New interfaces needed for plasma-desktop-session

store-requests privileged-interfaces
21

Fair enough. I’m super confused as to why it did install in the past then…

22

Maybe @jamesh updated the base declaration as per your request or you modified it locally?

23

If the assertion is ultimately just a text file with a GPG signature, is it not possible to use the underlying store key to sign a handwritten (likely, computer generated & manually modified) assertion? Ultimately to the recieving snapd clients, they’re just files on a web server.

Appreciate this might be one of those “We’d rather not” scenarios but ultimately if there’s a service in Canonical somewhere that’s generating signed assertions already, can it not be modified to allow an override and pass some of the responsibility onto the client side? Ultimately these are special cases from trusted publishers and there’s still human review.

Even easier, allow the review tools to simply be laxer for specific snaps, which I feel is already the case with e.g., setuid bits in certain key snaps (e.g., Chromium), what’s the difference between a single bit that gives root access vs an interface that does significantly less?

Edit: context for the above:

24

hi @kottens,

To confirm, we did manually approve the revisions but never added anything to the declaration for systemd-user-control. Sorry if there was any confusion from my end about that. My assumption was the same as @jslarraz, in that snapd on the testing device had been patched to override the interface and enable auto-connect.

25

Hey @James-Carroll

After discussion with @pedronis it seems that systemd-user-control will never land snapd and a different solution will be proposed for this use case. Thus, even if it may possibly be technically possible to generate such assertion, I definitively think we should not add anything to the production store that will not land the production snapd tbh.

If there would be any plan to add this interface to snap at some point the reasoning might be different. But at this point, I think it is just better to update the interface base declaration on the snapd fork side to allow the snap to install for testing purposes I think

1 Like
26

Hello @cav and @jslarraz

Fair enough, so I went with a patch to snapd and now it does install and autoconnects since I changed the base declaration.

Doing so I found other issues with the current store declaration:

  1. audio-record, audio-playback and pulseaudio used to be slots but they are plugs now (provided by the pipewire snap), this isn’t reflected in the declaration
  2. some slots didn’t auto-connect when I installed a snap application (e.g. firefox), those are desktop, x11 and wayland (screen-inhibit-control did auto-connect fine though)
  3. some plugs didn’t auto-connect when I installed plasma-desktop-session itself, those are audio-record, avahi-control, bluetooth-control, bluez, cups-control, hardware-observe, hostname-control, locale-control, login-session-control, login-session-observe, mount-observe, network-control, network-manager, network-observe, pipewire, process-control, pulseaudio, ssh-keys, system-observe and udisks2

Looks like I forgot some of those in my previous requests, there’s also been interfaces changing side from slot to plug… Sorry about those oversight, the change from using a base snap to using a content snap has been more impactful on the necessary declarations than I anticipated.

As for why I was remembering systemd-user-control installing properly… I traced it back to the fact that on the previous architecture we had to have a gadget snap and it was compensating for this. Some of the missing auto-connections above were also covered there.

This won’t do anymore as we’re moving away from having our own gadget snap.

Thanks in advance for your help.

27

audio-record, audio-playback and pulseaudio used to be slots but they are plugs now (provided by the pipewire snap), this isn’t reflected in the declaration

Sounds reasonable, I’ll update the declaration after approving and granting the pipewire plug

some slots didn’t auto-connect when I installed a snap application (e.g. firefox), those are desktop, x11 and wayland (screen-inhibit-control did auto-connect fine though)

If I understand it properly, these slots are now provided by the system and by plasma-desktop-session snap. In that case, the auto-connection won’t work (as it is not clear which slot the snap should plug into).

It is the same problem reported here for Brave and cups. This PR fixes the issue for the cups-control interface, giving preference to the slot provided by the host when available.

I don’t know if there is a more generic solution as of now (@jamesh mentioning you as the author of the cited PR).

some plugs didn’t auto-connect when I installed plasma-desktop-session itself, those are audio-record, avahi-control, bluetooth-control, bluez, cups-control, hardware-observe, hostname-control, locale-control, login-session-control, login-session-observe, mount-observe, network-control, network-manager, network-observe, pipewire, process-control, pulseaudio, ssh-keys, system-observe and udisks2

These are new requests that require voting from the reviewers before granting. I’ll try give it some priority to unblock you asap

Thanks

1 Like
28

There are no implicit system:desktop, system:x11, and system:wayland slots on an Ubuntu Core system. Instead they are provided by application snaps that implement those features.

On a Core Desktop system, the Wayland compositor and Xwayland server are run as part of the desktop session snap (ubuntu-desktop-session or plasma-desktop-session currently). The base declaration does not allow these interfaces to auto-connect on Ubuntu Core systems, so a store assertion is needed on either the plug or slot side. Since there is one desktop session installed and a massive number of application snaps that are mostly targeting classic systems, it makes sense to handle this on the slot side.

This is different to the case of the cups snap on classic systems. There we had both system:cups-control and cups:cups-control slots as potential connection candidates resulting in neither being connected. The PR you mentioned is a hack to make sure only one of the slots is connectable at runtime depending on the presence of a non-snapped printing stack.

29

Thanks @jamesh

You are absolutely right, my bad. I just wrongly assumed that auto-connection was enabled for those interfaces independently of the platform and slot type. x11 and wayland seems to only auto-connect on-classic, while desktop only auto-connects if the slotting snap is not app type.

Thus, I agree that a slot-side declaration is the correct way to handle this. I guess it will also need voting

30

Just took a deeper look to the newly requested interfaces. It looks reasonable overall but still have few questions

  • Why is audio-record (+ audio-playback) not enough and deprecated pulseaudio is still required?
  • Whilst most of the requested interfaces looks reasonable to me, many of them seems to not be used by ubuntu-desktop-session ( avahi-control, bluetooth-control, bluez, cups-control, hardware-observe, hostname-control, locale-control, login-session-control, login-session-observe, mount-observe, network-control, network-manager, network-observe, pipewire, process-control, ssh-keys, system-observe and udisks2). Could you please provide some insights what is the reason for this difference? Are those connected by a gadget snap there atm? I would expect both snaps to have similar requirements
  • Regarding ssh-keys, it is a highly sensitive interface. Could you please explain what is it used for?

Thanks

31

Why is audio-record (+ audio-playback) not enough and deprecated pulseaudio is still required?

I admit I never tested without pulseaudio, for sure we have a component in the session which really needs to talk to pulseaudio unencumbered because of the volume control. I just checked but it looks like we can do without it indeed.

Whilst most of the requested interfaces looks reasonable to me, many of them seems to not be used by ubuntu-desktop-session ( avahi-control, bluetooth-control, bluez, cups-control, hardware-observe, hostname-control, locale-control, login-session-control, login-session-observe, mount-observe, network-control, network-manager, network-observe, pipewire, process-control, ssh-keys, system-observe and udisks2). Could you please provide some insights what is the reason for this difference? Are those connected by a gadget snap there atm? I would expect both snaps to have similar requirements

It’s a combination of three things:

  1. there is indeed a gadget snap which pre-connects quite a few of those interfaces in the ubuntu-desktop-session case
  2. we have a bit more composants by defaults in the plasma session, and they have their own needs
  3. ubuntu-desktop-session doesn’t yet account for some of the latest changes in architecture I think (I’m thinking of udisks2 and pipewire in particular)

Regarding ssh-keys, it is a highly sensitive interface. Could you please explain what is it used for?

I think we can do without this one. As long as it doesn’t prevent the use of admin-console from the session (that does a ssh to localhost) we should be fine.

32

Thanks a lot for info @kottens .

+1 from for granting following plugs and slots:

Slots: desktop, x11 and wayland

Plugs: audio-record, avahi-control, bluetooth-control, bluez, cups-control, hardware-observe, hostname-control, locale-control, login-session-control, login-session-observe, mount-observe, network-control, network-manager, network-observe, pipewire, process-control, system-observe and udisks2

Let’s give it a try without ssh-keys first and we can discuss about it if it is absolutely needed

33

Thanks for your patience @kottens !

Similarly to what has been discussed, +1 from me for

Slots:

  • desktop
  • x11
  • wayland

Plugs:

  • audio-record
  • avahi-control
  • bluetooth-control
  • bluez
  • cups-control
  • hardware-observe
  • hostname-control
  • locale-control
  • login-session-control
  • login-session-observe
  • mount-observe
  • network-control
  • network-manager
  • network-observe
  • pipewire
  • process-control
  • system-observe
  • udisks2
34

+1 from as well for based on the above discussion to these plugs and slots

35

Hey folks,

I’ve done some updates to the snap declaration

audio-record, audio-playback and pulseaudio used to be slots but they are plugs now (provided by the pipewire snap), this isn’t reflected in the declaration

I’ve removed those ones from the slot side

some slots didn’t auto-connect when I installed a snap application (e.g. firefox), those are desktop, x11 and wayland (screen-inhibit-control did auto-connect fine though)

I’m struggling to understand why it was not working already.

For those interfaces (desktop, wayland and x11) the declaration looks like

{
  "allow-auto-connection": {
    "on-classic": "false"
  },
  "allow-installation": {
    "slot-snap-type": [
      "app"
    ]
  },
  "allow-connection": {
    "on-classic": "false"
  }
}

whilst for inhibit-screen-control (which was properly working) looks like

{
  "allow-auto-connection": {
    "on-classic": "false"
  },
  "allow-installation":  "true",
  "allow-connection": {
    "on-classic": "false"
  }
}

Thus, I think the only possible difference should be with the installation and not the connection/auto-connection

Also the declaration for desktop, wayland and x11 is the same that we have for ubuntu-desktop-session

I don’t know what would be the best way to debug it on my side as I don’t have access to any ubuntu core / core desktop system atm. Could you please share the output of snap connections on your system?

some plugs didn’t auto-connect when I installed plasma-desktop-session itself, those are audio-record, avahi-control, bluetooth-control, bluez, cups-control, hardware-observe, hostname-control, locale-control, login-session-control, login-session-observe, mount-observe, network-control, network-manager, network-observe, pipewire, process-control, pulseaudio, ssh-keys, system-observe and udisks2

Granted everything in the list except pulseaudio and ssh-keys as discussed. Also pipewire is not granted yet as it is a bit special as of now and I would like to fix issues in 2. first.

36

Hey @jslarraz

Could finally reach a system to test.

Could you please share the output of snap connections on your system?

The output is available there: https://ervin.ipsquad.net/share/snap-connections.txt

I just manually connected pulseaudio and pipewire. The rest is what you get after a first boot on an Ubuntu Core Desktop system where both firefox and plasma-desktop-session are installed. I’d have expected firefox to connect to desktop, wayland and x11 on both plasma-desktop-session and ubuntu-desktop-session.

Granted everything in the list except pulseaudio and ssh-keys as discussed. Also pipewire is not granted yet as it is a bit special as of now and I would like to fix issues in 2. first.

I checked, and we indeed need both pulseaudio (still) and pipewire plugs to be connected for plasma-desktop-session sound support to fully work.

37

You should drop the pulseaudio plug: you should get all of those permissions from audio-playback + audio-record. It made sense to provide a pulseaudio slot when you had the sound server within your session snap for the benefit of old snaps that are still trying to plug that interface. That’s now the responsibility for the pipewire snap.

It does make sense to autoconnect the pipewire plug though: the desktop session snap needs this extra access to support things like screen sharing (i.e. where the compositor sends a video stream to Pipewire to be passed on to other applications).

38

You should drop the pulseaudio plug: you should get all of those permissions from audio-playback + audio-record.

Well, that was my expectation as well, but something’s clearly amiss. The sound control applet doesn’t work at all without the pulseaudio plug being connected to the pipewire corresponding slot.

Didn’t investigate where the discrepancy is yet.

It does make sense to autoconnect the pipewire plug though: the desktop session snap needs this extra access to support things like screen sharing (i.e. where the compositor sends a video stream to Pipewire to be passed on to other applications).

Yes, definitely.

39

OK, after a quick check in the implementation I think I found something. @jamesh I’ll contact you by email for this to avoid derailing this thread too much.

40

  • Regarding pulseaudio we should find what is missing and add it to audio-playblack or audio-record if that makes sense

  • Regarding pipewire, agree it should be auto-connecting. Just waiting until issue with slots auto-connection would be fixed as granting pipewire may have some implications at the store side given that pipewire has not been added to review-tools yet. But It will be granted for sure :slight_smile:

  • Regarding the slots auto-connection, from the output of snap connections you shared, I can see that ubuntu-desktop-session is also installed on the system. That should prevent the auto-connection as it would run into the problem of several connection candidates. The most interesting part here, is that firefox seems to be auto-connecting ubuntu-desktop-session, what makes me think that plasma-desktop-session is not even considered a connection candidate by snapd. Also the snap-declaration for those slots are identical for ubuntu-desktop-session and plasma-desktop-session snaps as far as I could see. I’m not sure what might be the problem here tbh