Classic confinement request for ubup

@evan - can you or someone from the snap advocacy team take a look at this?

1 Like

Hey, any news on this? : )

Hey, any news on this? : o

Sorry for the delay, we’ll look at this in the morning.

I’m happy that Tim is the upstream developer for this application, so is authorised to speak and publish on behalf of the project. However, the application falls into a set of tools we don’t grant classic to, that is applications which are scripts to download software from elsewhere to run on the machine.

When that rule was set out I’m not sure whether it was intended to catch those scripts which are essentially just a bunch of add-apt-repository, apt-get and curl | bash commands bundled together, or anything which can be used (as its primary purpose) to install and run other software. Perhaps @jdstrand can expand on that?

It feels like this isn’t so much “a collection of apt commands” as a “tool for orchestrating software installation” which is a different beast, and if that’s the case, I’d +1 it, with @jdstrand clarification above.


I agree that as a tool for managing software installation, controlled by the user, I’d +1 this request.

Considering that I would like to ship Ubuntu MATE Welcome and Software Boutique as classic snaps, which also install software under user control, I’m keen to hear @jdstrand’s thoughts.


I gave my thoughts here:
Classic confinement for yarn. I’ve asked for comment from an architect.

1 Like

Hey @jdstrand, @popey and @Wimpress, thanks a lot for your replies.

I personally think that in that respect ubup is actually very similar to the classic snapcraft snap.
Both can download and run arbitrary scripts or programs and install arbitrary software to the system.
However, in both cases, the user has full control over what is installed and (to some degree) how (both use a quite similar yaml format).
That’s just my two cents.

Looking forward to a decision on this topic!

@niemeyer responded specifically for yarn.

@niemeyer, this is the one I was thinking about when I commented in Classic confinement for `node` snap. Can you weigh in on this one? This one is even bigger than an ‘installer snap’ in that it allows you to automate installing packages and other administrative tasks.

This is indeed a different case from yarn, in that its main purpose is actually to manipulate the Ubuntu system itself in arbitrary ways, including the manipulation of pretty much every package management system on behalf of the user.

The software itself seems fine and I would encourage to package it and distribute it, but it feels slightly inappropriate to convey that as a classic snap, at least at this stage.

I suggest we wait a bit and learn more about how classic snaps are used and interact with the system, and come back into this.

1 Like

@niemeyer @jdstrand thanks a lot for looking into it and for your response.

This is indeed a different case from yarn, in that its main purpose is actually to manipulate the Ubuntu system itself in arbitrary ways, including the manipulation of pretty much every package management system on behalf of the user.

I do see some sensible arguments for denying classic confinement to this sort of snaps.

However, I am missing some sort of set of formalized rules specifying where exactly the red line between approval and disapproval lies here.

For example, the classic snapcraft snap is also able to install arbitrary software and manipulate the system in arbitrary ways with two main differences:

  • the target users are developers
  • the goal is packaging software rather than setting up a system

Therefore, is the decision between approval or disapproval also related to the target audience (“regular users” vs. “power users” users vs. developers)? Or is it solely based on what the packaged application is theoretically able to do to the system? Or is it more important what the publisher says the application mainly aims to do?

Since the snap store is a centralized store, application publishers are dependent on the approval of the store owners (or “gate keepers”). Unlike with other packaging systems, there are no alternative repositories or other ways to properly distribute snap applications.

Thus I think that from a publisher perspective, clear, transparent rules for whether or not a snap applies for classic confinement are crucial.

Maybe Process for reviewing classic confinement snaps could be expanded with such rules? Thanks :slight_smile:

1 Like

Hi Tim,

Thanks for bringing those issues up. Indeed we need to be extremely transparent when discussing store issues, precisely because this is a shared resource that we all care about. That’s why those conversations are happening publicly here, and are available for debate.

For classic snaps, we don’t yet have that clear line that defines when it is okay and recommended to use them, and when it is better to work harder on confinement or alternative distribution means. We lack enough experience with them to have that clarity right now.

For that reason, you’ll find interesting conversations as happened for yarn with multiple people debating what’s the right thing to do, and providing rationale for it. I hope we can eventually take those experiences and drive a more clear line, as you suggest.

Answering your more specific questions, the issue is definitely not related to what the application can theoretically do, as every application can theoretically do everything.

Being clearly oriented for developers helps, as developers are much more conscious of the issues related to the installation and use of libraries that they themselves depend upon.

The case of snapcraft is an interesting one. We might see it as a unique exception since it’s one of the pieces that enable the whole thing to fit together, but it’s not just that. I would probably have recommended accepting it nevertheless, because the driver for using snapcraft is building and packaging software instead of just manipulating the system in arbitrary ways. In fact, the latter is one of its deficiencies that we are working to fix, and you can even see me complaining here in the forum about the fact it wants to fiddle with packages. In the medium term, snapcraft should be entirely confined too.

In fact, another aspect that plays a role is precisely whether this is a temporary measure towards confinement, or if the application is inherently hard to confine. In the medium to long term the goal is to remove the need to have classic snaps all together, by implementing the necessary confinement features in a convenient way both for the developer and for the user.

Another aspect in those choices is the size of the community that depends on the given functionality. In the case of yarn, for example, its relevant following inside their own community means many of the concerns I’d have for such a fiddly piece of software are already real concerns on the maintainers’ table. So improving its distribution seems like a worthwhile trade off.

So these are some of the issues that surround the conversation of classic snaps, and given the number of aspects and the subjectivity in some of them, we can see why we don’t yet have a clear red line we wished for. What we have for now are these underlying goals, which work as guidelines for the conversation.


Hey @niemeyer, thanks a lot for your extensive response and explanation. If the medium or long term goal is to get rid of classic confinement entirely, I agree with your points.

Nevertheless, I think that there are some applications that can hardly be confined at all. Those however would not be suitable for being shipped as a snap packages then. For example, while many developer tools in general will be hard (but not impossible) to confine, some things like ubup are impossible to confine and only aim to work in a classic environment anyway.

When creating a snap packaging for ubup, I knew it would only ever work using classic confinement. The reason for choosing snap was because even without the confinement aspect it’s still a great way to package and distribute software. As I wasn’t aware that the medium/long term goal is to get rid of classic confinement entirely, I didn’t think much about whether or not ubup would be a suitable case for a classic snap. I saw classic confinement as a complement for confined snaps rather than as a way to workaround confinement limitations.

Maybe I’m the only one who had misconceptions about this, but in my defense I can say that I couldn’t find any documentation about this. The addition of some clarifications to the confinement docs page might prevent confusion about the nature of classic confinement in the future.

Anyway, thanks a lot for taking the time to review this and for clearing things up. :slight_smile:

Glad to exchange ideas on the topic, and to be clear the issue isn’t about having misconceptions on the topic, but rather that the topic is still being discussed and explored. None of the presented points would be definitive in isolation.

the issue isn’t about having misconceptions on the topic

With “misconceptions” I was only referring to the mid- or long-term goal of getting rid of classic confinement eventually which I wasn’t aware of and which - at least in my case - lead to misconceptions/false assumptions about what applications should apply to classic confinement.
Given this goal, my conclusion is that applications that will never be able to run properly confined and won’t aim to (like ubup) should not be distributed as classic snaps in the first place. Am I wrong?
This is quite different from my previous view of classic snaps not being a way to workaround confinement limitations but rather being a complement to confined snaps for classic systems.
Thus I think this context (nature of classic confinement) is important.

Per earlier point, none of the concerns presented would drive the decision one way or the other in isolation. One might easily argue that we’ll never be able to confine yarn properly as well, but that may not be true (the roadmap is pretty rich), and the other points presented in the thread are relevant too.


Thank-you all for discussing this. In what ways does the application not fit into a strict confinement? I think it is important to get the use-cases documented so that the snapd guys can drive creative ways of implementing interfaces for such use cases that allow a fine-grained control over snaps. For example, being able to interact with the Debian Package Manager could be a great candidate for a set of new interfaces:

  • deb-observe: see which packages are installed
  • deb-install: allows to install new packages, and
  • deb-remove: allows to remove packages, or in addition or instead of those last two
  • deb-control: allows both installation and removal of packages

We can replace deb-install and deb-control by root-my-machine. :thinking:

1 Like

Well, yes, it would need to be a restricted interface by considered request or manual connection only. But not having the interface leads to requests for “classic” where “root-my-machine” is even more possible.

Consider, however, an Ubuntu Core system where the root file-system is read-only and classic is on-top; on such a system a classic snap cannot work, but a properly authorized strict snap can, and this potentially allows for more uses of the same snap where using classic would be restricting it to “normal” systems.

1 Like

Sure, but what’s at stake here is what “properly authorized” means. If an interface gives unconfined access to the root user in the system, that’s not very “strict”.

We did discuss a while ago the possibility of introducing an interface which would be a bridge between the classic snap world and fully confined snaps. Something like an “unsafe” interface. It would give the full access into the system, but keep the snap mounted in its usual namespace as usual otherwise.

That’s pretty close to what you refer to, except we’d label and consider access requests for what it is. It would also require the same sort of user acknowledgement on installation as classic (–classic, etc).