I’m working on a small utility that switches out system utilities with equvialents written in Rust. An example is replacing coreutils with rust-coreutils but in a way that can be easily enabled/disabled.
The tools is written in Rust, and needs to manipulate installed packages, as well as files/symlinks in places like /usr/bin, /usr/lib/cargo/bin, and thus needs classic confinement in order to be effective. It will also likely need to manipulate config files etc.
name: oxidizr
description: “Tool for enabling/disabling experimental Rust-based packages on Ubuntu”
supported-category: fits under criteria of debug tools .
reasoning: Needs to install/remove packages on the underlying system, and manage new symlinks in privileged locations such as /usr/bin, /usr/lib/cargo/bin, /usr/sbin, /etc, etc.
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.
Whilst it probably doesn’t fit very well under tools for local, non-root user driven configuration of/switching to development workspaces/environments because of the non-root user part (it performs privileged operations as described in the reasoning field), the technical requirements are clear and I agree it may fit under the debug tools category considering the purpose of the snap.
Sounds more like “third party package management tool” to me TBH (which we strictly deny normally)
I must admit i find it slightly problematic when we allow employees to sneak past the limitations we set ourselves…
I.e. your last classic request was a file manager around which I had at least a handful different (and partially heated) discussions with community developers over the ten years snaps exist that wanted to snap various of them, what will I tell the next one that comes up with a request of that kind and that points to one of these approved classic requests ?
Could we/should we expand the “supported categories” with “does not apply to Canonical employees” if we allow ourselves this kind of exceptions so it is at least explainable to the community ?
Oops, that wasn’t my intention at all. Apologies if it comes across that way. I’ll admit to hastening a response to my request, but I’m not trying to subvert the review process.
I don’t think this qualifies as a third-party package manager - in that it’s really just calling apt-get in the background to install packages already available in the archive. Perhaps I’ve misinterpreted the guidelines?
This is pretty similar to concierge which is a tool for provisioning/configuring test environments for snaps & charms – again relying on snap and apt to ensure that the relevant packages are available on test machines, and in the category of debug tools.
On the file manager point I’ll have to plead ignorance, I wasn’t aware there was such a history with file managers/snaps.
Heh, well, that history is mostly in my memory (i think one or two are documented here on the forum though (look for gnome-commander), most were in direct discussions on IRC though)
Another point is, that snaps have to be self contained and universal, classsic ones even more than strict ones since it is very easy to leak the outside env into the snap or vice versa (which should never happen)… i.e. will your snap run on gentoo, fedora, arch ? Else it breaks the promise of snap being a universal package format across all distros …
Note that I don’t want to turn down this request or anything, I just want to make sure our rules are reflecting reality enough so we do not anger the community, I’m totally not opposed to change them as needed
In this case no, because the software itself is not cross-distribution. It is a tool built for manipulating Ubuntu machines - and it will exit if it detects something else.
But I suppose the package will technically still work
@jnsgruk is it a requirement that the snap change the system installed packages - could it instead manage a set of things installed in its own location and then just instruct the user/sysadmin to update PATH to prefer its set over the ones installed in the system? Then it could work without needing such pervasive access itself.
It could, but that isn’t really the effect I was going for. The idea is to simulate what would happen if we actually replaced these packages and made them the default in Ubuntu.
If it’s too much for a snap then I’ll just ask people who are interested to cargo install or build from source I guess
I’d hope it would be pretty obvious that this is a dangerous app:
You’d have to specify --classic to install
It must be run as root
I can also add a prompt with a sort of “are you really, really sure you want to do this” sort of message if that helps.
So the issue is we have a pretty clear Process for reviewing classic confinement snaps which outlines the supported categories for classic confinement - and in this case this snap does not really fit in the suggested debug tools category - and instead fits more in the unsupported category of 3rd party installers - and so the clear answer really is that unfortunately your snap is not supported by an existing category and so we cannot grant it classic confinement.
As @ogra alluded to above, this is complicated by this being a request coming from a quite senior team member at Canonical, which then leaves folks on the reviewers team feeling some pressure to approve the request in spite of it not fitting within the categories. We want to have clear processes and expectations that we can apply to both internal and external requests and so we really want to avoid having to grant exceptions to snaps from Canonical team members which we would not otherwise grant to anyone else.
As such, if you really need this to be a classic snap, the only way forward is to have a Snapd architect change the list of supported/unsupported categories to make it clear that we can start granting classic confinement to snaps with this kind of use-case.
But for now, this request doesn’t fit in a supported category so we cannot grant it.
