Classic confinement request: SnapMan

store-requests classic-confinement
1

  • name: snapman

  • description: SnapMan is a single-purpose, user-invoked CLI for reclaiming disk space by cleaning up disabled Snap revisions. It reports disabled revisions (dry-run) and can remove only disabled revisions after explicit user confirmation. It does not install software, manage services, run daemons, or provide general snap management

  • snapcraft: snapman/snapcraft.yaml at main · ersinakyuz/snapman · GitHub

  • upstream: GitHub - ersinakyuz/snapman: A lightweight CLI tool written in Go to clean up old, disabled snap revisions and free up disk space on Ubuntu (flavours).

  • upstream-relation: I am the upstream author and maintainer of SnapMan.

  • supported-category: debug tools

  • reasoning: SnapMan needs classic confinement because it must operate on snapd-managed host state to remove disabled revisions. This is a maintenance/cleanup use-case, initiated explicitly by the user in the terminal. It is not a general “management snap”.

    What SnapMan does (scope-limited):

    • Reads snap list --all to detect disabled revisions
    • Presents a clear list and the potential disk space gain
    • Removes ONLY disabled revisions, and only after explicit confirmation (unless the user passes --assume-yes)
    • Provides --dry-run to report without any changes

    What SnapMan does NOT do (to avoid “management snap” behavior):

    • Does not install or update other snaps
    • Does not enable/disable snaps or services
    • Does not run as a daemon or background agent
    • Does not provide a general UI or API for snap administration
    • Does not attempt to bypass snapd policies; it relies on snapd’s standard behavior for removals

    Why strict confinement is not sufficient:

    • The core action requires removing disabled snap revisions, which is a snapd-controlled operation affecting system-managed state.
    • Under strict confinement, a third-party snap cannot reliably perform the required snapd operations for removing revisions in a supported and secure way using existing, auto-connectable interfaces.
    • The required capabilities effectively amount to system-level snap maintenance, which is outside what strict confinement interfaces are intended to grant to an unprivileged application.

    Safety and user control:

    • SnapMan is intentionally conservative: it targets disabled revisions only and never removes active revisions.
    • Default behavior is interactive confirmation; --dry-run is available and recommended.
    • The project is fully open source (MIT licensed) and auditable.

I understand that strict confinement is generally preferred over classic. I’ve tried the existing interfaces to make the snap to work under strict confinement.

Please grant classic confinement for snapman so I can publish it to the stable channel.

2

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

3

Hey @ersin2k

Technical reasons why SnapMan needs classic to work are clear, but please note that classic confinement is a sensitive matter and it is reserved for mature, well-known applications published by mature, well-known entities. As of today, I believe that SnapMan doesn’t meet this criteria because of the following reasons:

  • The project seems to be very fresh, according to the upstream repository

  • The projects seems to have little/none community around according to upstream repository (contributors, issues, PRs, etc.)

  • I could not find evidences that the project has a strong enough user base currently

I really like the functionality provided by SnapMan, but, considering the factors presented above, I think SnapMan should not get classic confinement as of now.

Sorry for the inconvenience

4

How exactly compares what snapman does to gdb, valgrind or any other debug tools ? This definitely does not look like a debug tool to analyze code at all …

This is definitely not a reason for classic confinement, talking to snapd from within a snap must happen through the snapd-control interface (which is reserved to canonical owned snaps and brand store owners (who own the devices attached to their brand store)) and not through calling the snap commandline tool …

Please also note that package managers of any shape or form are explicitly in the denied list for classic confinement (see the “unsupported” list on: Process for reviewing classic confinement snaps )