supported-category: “tools for local, non-root user driven configuration of/switching to development workspaces/environments”
reasoning: The tool must run apt and snap to install and configure tools
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.
This is a Canonical roadmap item and I am requesting classic confinement in my capacity as a Canonical developer.
(This is a re-submission; I had previously written a version of this software that did not adhere completely to the snap guidelines due to how it used sudo.)
I’m not in the reviewers team, but usually Hand-Hold all classic requests a little (playing the secretary to make sure all information is added etc).
Classic is a very sensitive matter so we need to make sure everything is transparent and open to have a public paper trail, something like an internal quick path would be a very bad idea…
Depending on the complexity and on the available information a classic request can take between two weeks and depending on complexity (publisher vetting etc) a little more time…
Seems this request is only 7d old yet, so still within the average time frame I’d say
I just took a short look at the source and also cross checked the request itself and there are a bunch of issues:
Snaps come with the promise that you can install them on any distro where snapd runs, this:
…actually clashes with this promise unless the snap also supports install methods for i.e. fedora, SuSE, Arch, etc
Along with this we have a explicit entry in the unsupported categories at:
Saying:
Unsupported:3rd party installer snaps (eg, for native packages, AppImages, Flatpaks, Snaps, etc)
(also see point 2 in the “Caveats” paragraph)
Beyond this, looking at the source I notice that it does not make sure that the host environment can never leak into the snap env and vice versa.
Usually there is a lot of binary patching inside classic snaps to prevent exactly this. Is everything inside there compiled statically ? Are all rpath calls (if any) patched out so that it can not accidentally use the hosts linker or libc (all binaries inside the snap need to be linked against the base snap it uses)
@petrakat given the clashing of categories I fear you will likely need an architect (i.e. @niemeyer, @pedronis or @jnsgruk would be able to overrule the clash) to approve it …
Yes, I am aware that it violates some of the Snap guidelines. However, this is one of our roadmap items, so I am doing everything I can to make people’s lives easy and get it approved.
I will work on packaging the things currently installed via apt into Snaps.
Hello, would it be possible to install the programs with cargo install instead of apt? All the programs we previously were planning to install with apt are also installable with cargo install. It puts the binaries in ~/.cargo/bin, similar to Rustup putting things in ~/.rustup/...
In this case I think it would be better to use cargo install, yes. That gives this half a chance of working across distros, and also stands less chance of malfunction due to the host environment leaking.
Regarding cargo install: I have very limited knowledge on Rust and would like to understand if it is possible to achieve the desired functionality using strict confinement by staging dependencies (e.g. rustc, gcc etc.) within the snap itself?
devpacks go into the “tools for local, non-root user driven configuration of/switching to development workspaces/environments” part of the Supported category:
devpacks go into the “tools for local, non-root user driven configuration of/switching to development workspaces/environments” part of the Supported category:
I agree that the snap fits within this supported category. However, it is not enough to get classic confinement. Current policy is that:
The application must clearly fit any of the supported categories for classic.
There must be valid technical reason why strict confinement is not enough
Technical reasons and application functionality must not fit under the unsupported ones.
In this case, the technical reason / functionality is explicitly listed as unsupported 3rd party installer snaps (eg, for native packages, AppImages, Flatpaks, Snaps, etc). An architect may override it for this concrete snap, and my impression from @jnsgruk comment is that this looks fine to him if cargo install is used (please correct me if I’m wrong).
Hello, would it be possible to install the programs with cargo install instead of apt? All the programs we previously were planning to install with apt are also installable with cargo install. It puts the binaries in ~/.cargo/bin, similar to Rustup putting things in ~/.rustup/...
As @shishirsub10 pointed out, we must ensure that there are real technical reasons why strict confinement is not enough. I’m not very familiar with the Rust environment, but from this commentary I also wonder whether granting access to ~/.cargo/bin and ~/.rustup/ via personal-files interface would be enough, and/or what are the technical limitations otherwise.
Hello, I do recognize that installer snaps are generally not allowed, but I was working under the assumption that rustup itself provides precedent for an exception. (I asked the Snap team internally a few times but never got a response.)
Is classic confinement required to run sudo or otherwise install other snaps? (It seems like it should be.) However, if this is not the case, I think everything devpack-for-rust does can be done in the home directory – I will do some tests now.
The programs that devpack-for-rust installs can be run on any file; because of this I did not previously explore non-classic confinement. It seemed to me that installing programs that could escape the snap sandbox was against the spirit of the rules. However, if this is the way forward, I will be happy to do it.
@shishirsub10: I don’t believe this would be a good idea as part of the point of the snap is to install rustup itself. It would be extremely wasteful to re-include all of rustup inside the snap; in addition I worry about the portability of programs compiled within the snap sandbox.
Sudo is generally nothing a snap can use or rely on.
You can have a pop-up/message that tells the user to run the snap shipped binary with sudo though, but you can not rely on sudo even being available on the host (you don’t know what distro your snap gets installed on) and due to sudos design you can’t ship it inside either…
I guess that is what the “tools for local, non-root user driven” bit for the permitted category means
Hello, I do recognize that installer snaps are generally not allowed, but I was working under the assumption that rustup itself provides precedent for an exception.
exceptions needs to be granted in a case by case basis by an architect
Is classic confinement required to run sudo or otherwise install other snaps? (It seems like it should be.)
I believe snapd-control can be used for this. It also needs an architect +1 but possibly this is a better alternative than classic (@pedronis wdyt)?
The programs that devpack-for-rust installs can be run on any file
These programs will run either unconfined or as a different snap (means different sandbox)
It seemed to me that installing programs that could escape the snap sandbox was against the spirit of the rules.
That’s partly why 3rd party installer snaps are unsupported I guess, but devpack-for-rust will do it regardless of its confinement model (strict or classic)
While snapd-control would indeed be a good fit to install the rustup snap, the devpack snap would still have to be able to execute rustup which it wouldn’t be able to do under strict confinement …
The situation looks to me like:
strict → no way to run rustup but ability to install via snapd-control access …
classic → no permission to run snap install due to policy but the ability to run rustup after it was installed …
What we’d actually need but what contradicts the snap design itself would be a dependency like we have in debian packages here. You could have a classic snap depending on the rustup snap this way … but this is something that was explicitly not wanted when snaps were designed originally …
A way out might be to change the rustup snap to be a content provider, the devpack could then refer to rustup as the default provider for this content interface (which would auto-install it alongside devpack), rustup itself could provide its commands via the content interface to devpack and devpack could be strict and use a personal-files interface to install rust in the homedir of the user …
But this would mean quite some packaging changes to the rustup snap to actually provide this functionality, not a small amount of work …
EDIT: another alternative would be to simply use rustup as a stage snap (i.e. bundle it), looking at the rustup snap it is below 5MB, that doesn’t seem too heavy honestly …
While snapd-control would indeed be a good fit to install the rustup snap, the devpack snap would still have to be able to execute rustup which it wouldn’t be able to do under strict confinement …
maybe desktop-launch interface can be used for this (unless it is limited to launch strictly confined snaps)
Not sure if the desktop-launch interface actually allows using snap run... (I have never actually used it), but to me it looks like it allows running apps/snaps via .desktop files only,..
My impression is that the devpack snap is actually supposed to be used on commandline too… (Someone who knows desktop-launch might need to clarify this)
