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?
Yes, I’ll make that happen.
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.
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.
References:
I would like to request pinning this topic in the store category.
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.
@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.
For the snap https://dashboard.snapcraft.io/snaps/t-rec 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…
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 …
This section is a bit confusing/overly condensed by parenthesis for me. It gives me the idea that HPC software qualifies for classic confinement, but only very specific HPC software that folks may or not be familiar with the internals of. A frequent challenge with High-Performance Computing software applications is that clusters typically have arbitrary directory structure; they don’t follow the Linux Filesystem Hierarchy. This isn’t modeled nicely by snapd/AppArmor. I can use the system-files interface, but now I have a “boil the ocean” problem where I need to add a declaration for every possible mount/file system setup that my users have.
I propose that we make the above clause simpler so that it’s more clear for what kind of HPC/orchestration software falls into this category. Let me know what you think of my attempt here:
Supercomputing software or orchestration agents that execute workloads on systems where the system itself is managed by an external application outside the control of the software/agent; the supercomuting software/orchestration agent simply manages the workloads running on the system, not the system itself.
- Note: It is possible to strictly confine supercomputing software and orchestration agents. You should first attempt to strictly confine your application before requesting classic confinement. Classic confinement will only be granted if snapd does not support a specific use case such as dropping privileges to become a specific uid/gid on the system, or the application requires read/write access to files and directories outside the Linux Filesystem Hierarchy Standard to function as end-users would expect it to.
A couple notes about my proposed revision:
- I replaced HPC with supercomputing. Not everyone is familiar with the HPC acronym, especially if you don’t work in the industry or directly work with supercomputers. I think supercomputer paints a better picture of ‘this isn’t your typical consumer-grade device’.
- I removed the reference to the thread need for user accounting. That thread is quite dense and there is not a clear resolution that can be easily pointed to as an example of why Slurm was granted classic confinement. There’s a lot of back and forth which makes the justification for why Slurm was granted classic confinement but maybe not other HPC applications opaque.
- I added a blurb about the Filesystem Hierarchy Standard. Almost every HPC workflow management application requires access to directories located outside of the
/home/<usr>directory. HPC applications will typically be chucked into a file system location like/optor other location, create user-specific configurations under home, and then access various kinds of mounted file systems such as NFS, Lustre, Ceph, etc.
Welcome to feedback on this!