Classic confinement request for maestro

store-requests classic-confinement
1

Hello Snapcraft team,

I am requesting classic confinement for my new snap maestro.

Description: > Maestro is a native GNOME graphical tool (built with Vala/GTK) designed to manage SystemD user services. It allows users to create, start, stop, and monitor services through a clean UI.

Technical reason for classic confinement: Maestro needs to interact directly with the host’s systemctl --user commands to manage services that live outside the snap’s sandbox. Since it orchestrates user services and processes that are part of the base system session, it cannot function under strict confinement.

Link to store: https://snapcraft.io/maestro

Thank you for the review!

2

Please see:

Your application needs to fit into one of the supported categories listed and must not touch anything in the list of unsupported categories at the same time to even be considered for classic, it is unlikely your app fits this requirement …

You should be able to use a personal-files interface to access the user services and could probably manage them via libsystemd from your app under strict confinement (not sure about the last one)…

1 Like
3

Hi ogra,

Thanks for your time on this.

So, I uploaded a new version. The app allows the user to create services that execute any binary on the system in /usr/bin. In strict mode, Snap does not have permission to execute binaries outside its own sandbox, which renders the app’s main function useless. Manage via libsystemd in strict mode prevents access to the session bus for Start/Stop commands on units dynamically created by the user in $HOME/.config/systemd/user, resulting in D-Bus permission errors (AppArmor DENIED) even with the standard interfaces..

4

Not a @store reviewer, the following is merely my own opinion on this matter.

First of all, you should use the request template in About the classic-confinement category for applying classic-confinement.

This shouldn’t matter as long as the binary isn’t executed by the app itself but by the systemd user service manager.

As per Process for reviewing classic confinement snaps , accessing software only available on host is an unsupported category of granting classic-confinement on the Snap Store:

Unsupported

  • dependent software only available on host (ship in instead snap (eg, stage-packages, build from source))

You’ll need to ship the said binaries within the snap, and do whatever compile-time/runtime configuration required to make it work in the snap runtime like accessing a certain D-Bus interface or Unix Domain Socket that is made available by one of the snapd confinement interfaces.

In this case, the following criteria for granting classic-confinement might apply:

Criteria

This lists some criteria that might require classic (non-exhaustive):

  • access to resources not yet supported by snapd and where the requirement is clearly understood to be supportable by snapd. This may result in temporarily granting classic until snapd supports the use case in strict mode

NOTE: while something may be known to require classic, that alone may not justify granting classic confinement.

However, it is a stop-gap solution that requires explicit approval from the snapd @architects after the use case is fully understood and is not an easy process.

You might also be able to make the snap work without applying classic-confinement if you can implement the missing snapd confinement interface(s) that allows the app to function in strict confinement and contribute it to the snapd project, see https://github.com/canonical/snapd/blob/master/CONTRIBUTING.md for the contributing guidelines.

As far as I can tell you’ll need an interface that ships the following similar AppArmor policy:

dbus (send)
    bus=session
    interface=org.freedesktop.systemd1
    path=/org/freedesktop/systemd1/unit{,/**}
    peer=(label=unconfined),
dbus (receive)
    bus=session
    interface=org.freedesktop.systemd1
    path=/org/freedesktop/systemd1/unit{,/**}
    peer=(label=unconfined),

with the following names:

  • user-service-control
  • user-service-observe

As a last resort, you can always distribute classic-confined snaps without store restrictions via other channels like GitHub Releases.

5

  • name: maestro

  • description: aestro is a native GNOME tool to manage systemd user services.

  • snapcraft: snapcraft.yaml

  • supported-category: orchestration

  • reasoning: Manage via libsystemd in strict mode prevents access to the session bus for Start/Stop commands on units dynamically created by the user in $HOME/.config/systemd/user, resulting in D-Bus permission errors (AppArmor DENIED) even with the standard interfaces..

:check_mark:I understand that strict confinement is generally preferred over classic.

:check_mark:I’ve tried the existing interfaces to make the snap to work under strict confinement.

6

Your description clearly does not sound like this is a tool doing cloud and HPC workload orchestration in datacenters (which is what is detailed in the description of the supported orchestratuon use cases) is the main focus of your tool to be used in such environments … ?

1 Like
7

Hi ogra

No, it’s really focusing on desktop. To create quickly systemd services, to run and stop them. I usually build webservices in dotnet and want to start them or stop them. This app helps with that, plus gives a visual feedback if a service is active or not.

I recorded a video of it working: maestro-repo/maestroPreview.webm at main · ivoxavier/maestro-repo · GitHub

Thank you for your time.

8

Hey folks,

Thanks @Lin-Buo-Ren @ogra ^^

I think the snap does not clearly fit any supported category and would require an override from an architect. Could you also clarify whether maestro is an open-source project? Otherwise, you would also need to go through the Verified accounts process

Thanks

1 Like