Mission Center - Manual Review Pending

store-requests
1

Hello :wave:

I am the main developer behind Mission Center.

I have uploaded a Snap package almost a week ago and it’s been in ManualReviewPending for most of that time.

What can I do to help here?

Thank you!

2

Hi, I notice your snap is blocked due to the following automated review issues:


human review required due to 'allow-installation' constraint (bool) declaration-snap-v2_plugs_installation (mission-center, kubernetes-support)
human review required due to 'allow-installation' constraint (bool) declaration-snap-v2_plugs_installation (system-desktop-files, system-files)
human review required due to 'allow-installation' constraint (bool) declaration-snap-v2_plugs_installation (user-desktop-files, personal-files)

As per the Process for aliases, auto-connections and tracks can you please outline what access your snap requires from each of these interfaces and why it needs them? In particular, kubernetes-support seems odd since this should only be used by snaps which are themselves a kubernetes distribution or similar (like microk8s etc) - and then can you please provide the details of the personal-files and system-files accesses that your snap is requesting as well (including the full interface declaration from your snapcraft.yaml or similar). Thanks.

3

Hi Alex,

Thanks for the quick reply.

kubernetes-support indeed is overkill for my needs, I actually need read-only access to /sys/fs/cgroup/*. I use this to match between processes and installed applications. But I haven’t found a suitable alternative that works.

The system-files plug is declared as follows:

  system-desktop-files:
    interface: system-files
    read:
      - /var/lib/snapd/hostfs/usr/share/applications
      - /var/lib/snapd/hostfs/usr/share/icons
      - /var/lib/snapd/hostfs/var/lib/flatpak
      - /var/lib/snapd/hostfs/var/lib/snapd/desktop
      - /var/lib/snapd/hostfs/snap
  • /var/lib/snapd/hostfs/usr/share/applications: List installed classic applications
  • /var/lib/snapd/hostfs/usr/share/icons: Find the icons for said applications
  • /var/lib/snapd/hostfs/var/lib/flatpak: Find installed Flatpak apps
  • /var/lib/snapd/hostfs/var/lib/snapd/desktop: Find installed Snap apps
  • /var/lib/snapd/hostfs/snap: Access the icons for installed Snaps

The personal-files plug is declared as follows:

  user-desktop-files:
    interface: personal-files
    read:
    - $HOME/.local/share/applications
    - $HOME/.local/share/flatpak/exports/share
  • $HOME/.local/share/applications: Find locally installed applications
  • $HOME/.local/share/flatpak/exports/share: Find locally installed Flatpak applications

For completeness this is the Snap package build yaml.

4

Allowing full access to /snap seems overkill just to get access to the snap icons - instead there are a couple snapd PRs in progress to allow this via daemon: add /v2/icons/{snap}/icon/{app} endpoint to return app icons by olivercalder · Pull Request #14214 · canonical/snapd · GitHub and interface/builtin: add desktop-files interface by Saviq · Pull Request #14331 · canonical/snapd · GitHub - so this should be used instead (@oac can you comment on the status of these?)

Regarding kubernetes-support - this is not able to be granted for your snap as it is not appropriate for this use-case - for snaps you could look at the security label to help identify which application a process belongs to - but I am not sure of something similar for flatpaks. Otherwise if your application really needs this access can you try via system-files to limit it to just the minimum required permissions? Thanks.

5

About kubernetes-support, it’s not just Snaps and Flatpaks, it’s also system apps (debs) launched via the desktop environment and it would be a huge burden to have to implement wildly different ways of detecting running apps. It’s already really finicky and error-prone with access to cgroup information since Snaps, Flatpaks and regular apps have different naming conventions for their respective cgroups.

I’ll try to use system-files as an alternative to see if I can add special handling in case of Snap packaging.

As for the icons, I can live without it for the time being if there is a solution in the works. The reason why the entirety of /snap is required is because, as opposed to desktop files, there is no place where all Snap icons can be found, each app has their icon buried in their respective snap directory.

Is there anything else from the list of permissions that you see as a blocker?

6

@alexmurray I’ve updated the snap package and published it.

Please let me know if there are any other blockers.

Thank you!

1 Like
7

@alexmurray Appologies for being insistent. Are there any other review blockers?

Thanks!

8

@alexmurray Any feedback as to why the review is still pending/queued would be great.

Thanks again!