Process for reviewing classic confinement snaps

Classic confinement review process


As of snapd 2.20, snappy supports confinement: classic which allows the snap to run without restrictions. Future releases of snapd will also support a classic interface (name TBD) that operates similarly. Snaps specifying classic confinement may target the stable channel, but are only supported on classic distro systems (ie, not on Ubuntu Core).

Because classic confinement snaps run without restrictions, use of classic confinement effectively grants device ownership to the snap. Due to the sensitive nature of classic confinement:

  • users must specify --classic when using snap install to install a snap using classic confinement
  • the review process in the snap store will flag for human review snaps that specify classic confinement
  • the store provides a mechanism for the reviewer to allow classic confinement to the snap so that subsequent uploads do not trigger human review
  • the publisher shall be vetted using the processes in this topic before classic confinement is granted by the store


  • reviewers are @reviewers
  • snappy architects are Mark, Gustavo, Samuele, etc
  • advocacy team is @advocacy
  • classic confinement is defined as confinement: classic and the upcoming classic interface (final name TBD)
  • classic confinement applies to a particular snap ID and may be revoked by the store


  1. the publisher makes the request for classic confinement in the forum using the store-requests category
  2. the technical reasons for why the snap uses classic confinement are gathered in the forum post and captured for potential future snapd improvements. The technical requirements will be reviewed by the security team and/or an architect
  3. the advocacy team, reviewers team and/or architects participate in vetting the snap/publisher
  4. once the publisher has been vetted, the technical reasons are captured and the request is approved, a store reviewer will issue a snap declaration for the snap and add a comment to the store, giving the URL to the forum post

Known categories

Classic requests generally fall under a number of categories. Below lists categories that developers may consult for things that are known to be allowed/disallowed use of classic confinement. @reviewers may consult these lists when processing classic requests. If something falls outside of these lists, then the requirements must be gathered by a senior reviewer and discussed with an architect (after which, it can be added to the lists).


  • compilers
  • debug tools
  • IDEs
  • juju helpers
  • kubernetes tools requiring arbitrary authentication agents
  • nautilus scripts
  • programming languages
  • public cloud agents
  • tools for local, non-root user driven configuration of/switching to development workspaces/environments
  • terminal emulators, multiplexers and shells
  • HPC or orchestration agents/software for running workloads on systems without traditional users where the systems are otherwise managed outside of the agent (ie, the software simply orchestrates running workloads on systems and doesn’t manage the systems themselves). Note: many HPC/orchestration applications can run with strict confinement and classic should only be granted if snapd does not support the specific use case (eg, the need for user accounting).
  • Installer snaps for Ubuntu Flavors based on the official ubuntu-flavor-installer


  • management snaps
  • 3rd party installer snaps (eg, for native packages, appimages, flatpaks, snaps, etc)
  • difficulty making strict confinement work
  • dependent software only available on host (ship in instead snap (eg, stage-packages, build from source))
  • access to dot files in $HOME (use $HOME instead of getent*, personal-files)
  • access to /etc (use layouts, system-files)
  • hard-coded paths (use snapcraft-preload, layouts)
  • ability to run other snaps directly (as opposed to defined interfaces)
  • access to arbitrary files on the system because the application isn’t designed with confinement in mind (if a desktop application, use portals or xdg-open)
  • access to arbitrary files on the system due to developer/user inertia (home and removable-media is almost always sufficient, though personal-files and system-files may be used under certain circumstances.
  • access to arbitrary files on the system to avoid increasing a snap’s size
  • GNOME shell extensions
  • nautilus extensions
  • access to org.kde.PlasmaShell.evaluateScript
  • access to org.kde.klauncher5 (klauncher) (modify application to launch programs directly)
  • direct access to sudo (modify program (eg, check if root and if not, alert user to run under sudo))
  • direct access to pkexec (modify program (eg, check if root and if not, alert user to run under sudo; note a polkit backend is planned but not roadmapped, so a snap may one day be able to use pkexec, but this is TBD)).


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

  • access to files on the host outside the snap’s runtime (eg, /usr)
  • running arbitrary command (esp if user-configurable such as a developer tool to organize dev environments)
  • 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.


Classic confinement sometimes might seem like the perfect solution to a publisher’s problem, but snaps that use confinement: classic differ from strict mode snaps in important ways:

  1. they are not installable on Ubuntu Core (all snaps) devices
  2. they run in the global mount namespace (ie, the host’s filesystem) as opposed to what is specified by base in the snap’s yaml.

Because of ‘2’, great care must be taken for the snap to work reliably across all distributions since, for example, as part of the build process snapcraft will adjust the snap’s binaries through binary patching and/or setting environment variables to look into the $SNAP directory for paths, either of which could affect the snap’s reliability when running on arbitrary cross-distribution host filesystems. In contrast, strict mode snaps use what is specified by base in the snap’s yaml as the basis for its root filesystem at runtime and can depend on it not changing.


Sometimes it might make sense for a snap to be allowed the use of classic (eg, for classic distro) but be usable in strict mode (eg, for Ubuntu Core). In these cases, rather than having two separate snaps, it is considered best to have two separate tracks, the default track and another called classicmode.


@niemeyer and @evan, can you review these processes?

Thank you Jamie, this is good. I have one lingering concern: can we do more to direct software vendors to the forum for this request? For example, could the feedback from automated review instruct them to create a forum post?

1 Like

Yes, I’ll make that happen.

1 Like

Per Classic confinement for Android Studio, we should consider members of the snapcrafters team as vetted if the snap is coming from one of the snapcrafters repositiories. @evan, @Wimpress and @popey (ie, the snap advocacy team which vets publishers) handle invitations to the team and vetting of team members and they review all PRs from members.

1 Like

Sometimes publishers request the use of classic for so-called ‘installer snaps’. One particular variant of installer snap is one that provides a frontend for manipulating traditional distro packaging repositories and software installation and removal which may or may not also include installing snaps.

In addition to the normal criteria outlined above, the following criteria should also be met when considering this variant of installer snap:

  • Is the snap an image frontend for applications (meaning it is being shipped in the image itself by the image builders)?
  • Does the the particular image (the Linux distribution or flavor) have a visible community behind it that would justify the snap to be publicly available?
  • Does the snap name, summary, and description clearly describe the use case, so people wouldn’t risk installing it without intending to? (for example, <distro name>-...-welcome, etc. Eg, ubuntu-mate-welcome)

Note that some ‘installer snaps’ (eg, gnome-software and software-boutique) are not distro-specific (eg, they work with any number of package backends) and therefore may not be required to be prefixed with <distro>-. These will be evaluated case by case using the above criteria as a starting point.



I would like to request pinning this topic in the store category.

1 Like

I’ve moved this back to the docs category because it’s linked to from our documentation (Snap confinement). Outside of docs, it’s not published and causes a 404.

1 Like

@reviewers - fyi, I added a ‘Known categories’ section to the first post in this topic (ie, the wiki portion) that should help us remember various categories. I doubt it is complete, but I can add them as I remember.

1 Like

For the snap I need to request confinement ‘classic’. This is needed because it needs to run arbitrary binaries on the end users system.

The original PR for the snap definition was created by @popey

you need to start a new topic in the store-requests category, this topic here is for discussing the review process, not for reviews themselves

Sorry, was my first day here, and I’m still a bit confused.


I would also suggest snaps that are capable of performing vulnerability scans - which require access to many system files, directories, and configs. For example, if OpenSCAP workbench ever became a snap, it would need to be classic so that it could perform it’s system scans without failure. Those tools tend to be very invasive, but highly useful for cybersecurity teams.

Hi @jdstrand and everyone,

Is this manual review process for snaps that require classic confinement necessary for every version update or just for the first time publishing of a new Snap?

Thank you

Just for the initial upload, once it is granted after a detailed review of the actual need for classic, a check if the uploader is trustable (i.e. if he/she is affiliated with upstream or works with their permission), and if the snap matches one of the supported categories above, there does not need to be further reviews, following uploads will just work…

Thanks @ogra, do you have any idea how long this process takes?

Also as far as I understood, if we decide to try using the supported interfaces instead of asking for classic confinement, some interfaces also require a manual approval request right?

the reviews themselves should start within two weeks after filing a fresh request (i.e. a new thread) in the store-requests category… then it really depends on the review, whether all info is available, publisher vetting has taken place etc

If you can use interfaces for your app and it can function, classic will usually not be granted …

super-privileged (or extremely powerful) interfaces will require a manual approval on first use (first upload with the interface plug added to snapcraft.yaml in fact), subsequent uploads with such a plug added will not …