That seems reasonable to me, and thanks for further explaining what you’re thinking about this.
This is the part I can’t quite provide any anecdotal use cases on, but I’m hoping others can chime in if they have real valid cases where this needs to work this way or if it should work the way that you’re suggesting. What you suggest of using strict or classic modes seems like sound reasoning.
To be perfectly clear, are you saying that --devmode should only be valid with --dangerous? Or, remembering that a ‘local snap’ might be fully asserted, are you saying that the following would also be allowed:
$ snap download foo
$ sudo snap ack ./foo*.assert
$ sudo snap install --devmode ./foo*.assert # --dangerous not needed due to 'snap ack'
I think the above should also be allowed. What shouldn’t be, at least as an initial discussion point, is “install by name downloading from the store”:
snap install foo --devmode
I hope this clarifies! Thanks for your questions, initially I did not think of this “local” case that you mentioned.
That would imply there’s no value in devmode at all. I think we already have some development oriented features today, in terms of logging for example, which seem worth having. Also, the logging in this particular case is different from a fully-confined snap, in that you’ll see logs for all denials, instead of stumbling upon the first denial every time.
But your point is an interesting one, that it is perhaps too easy today to encourage people to just go ahead and install things from the store unconfined.
I don’t think I see this. The owner and collaborators of the snap will still be able to install in devmode by revision. I just envision snapd getting a request like:
snap install foo --revision X
and once it gets the actual blob (that was given because the call was properly user authenticated so the store ACL checks decide the user is known and can access a non release revision), snapd installs it with confinement devmode cuz that’s what the store indicates is the confinement for this revision (which is what I first understood from your original post, when you said “But those revisions will only be usable by people with private access into that account, and via the –revision flag”).
My main worry is that the ‘foo’ snap I used as example shows up in the stable channel. So running “snap install foo --devmode --stable” does not fail in any way, nor warms the user about the risk he/she is buying into.
IMO, --devmode is a useful thing, in general. It seems worthwhile thinking through if the store interactions could be better, but I would caution against trading one set of pasteable instructions for another.
Perhaps we can improve it like this: today we consider local unsigned snaps as dangerous, and for those we force the user to acknowledge this fact by stating –dangerous in the command line. We could make snapd a bit more strict than that and also request that devmode be accompanied by either –revision, in which case it’s your own snap, or –dangerous, if it’s anyone else’s.
Are you suggesting to continue allowing devmode snaps in the store but require users to specify the revision and/or use the dangerous flag? That seems reasonable.
I just wanted to voice my opinion against eliminating devmode entirely. Some snaps by their nature tend to brush against the permissions boundaries, e.g. because they perform complicated configuration and system management. I don’t mind if the dangerous flag steers general users away from installing such snaps, but as a developer and system administrator, I would still like to use the snap store to distribute my software to Ubuntu Core devices.
That’s a very interesting point, because it’s both the reason why we want to disallow that confinement mode in channels, in the sense it’s being misused to conduct software unconfined instead of being used for development, but at the same time we want to look into your actual use case because we want to offer you a proper alternative to that which does not involve development mode flags.
Can you share with us what kind of access do you need into the system, and for which application?
I agree this is reasonable and is definitely a step forward. I would add one extra bit of strictness by ensuring that --devmode, in snapd, can only be used with --edge or --beta but never with --stable or --candidate.
Wanting to debug issues on a snap is orthogonal to whether it was released in stable or not. If we add the requirement of –dangerous to third-party snaps, that’s already much better than anything else people can already do by pasting shell commands from arbitrary sources.
I disagree, I think we should involve the community of testers as early as possible, even if the snap is very incipient. But the solution of strict snap on edge installed with --devmode works for me.
You disagree with what more exactly? What I said preserves your ability to do exactly that, and right after you disagreed you said it works for you. 
I disagree with this:
We actually have a classic-support interface and it has the very restrictive installation constraint in the base declaration (today, only the ‘classic’ snap in the store is allowed to use the ‘classic-support’ interface).
AIUI, the classic snap was initially installed in devmode so that nothing would be blocked since you can do all kinds of things to setup and use the chroot. It was found that there was way too much logging of ALLOWED apparmor messages and some time ago I added rules that silenced them (or put another way, it should be able to run in strict mode with little or no modifications). I’m not sure why the snap was left as devmode; I think we wanted to wait and see how those changes played out and then it stayed that way due to inertia. The policy is very lenient though-- the classic-support interface policy allows for some bind mounts and copying files into the chroot then uses systemd-run to start an unconfined session in the chroot’d dir.
Considering all this, I agree the snap could start in strict mode and we can simply fix the issues as they arise. If it doesn’t already exist, we could add a spread test for the classic snap to verify it is able to setup, reset and run a command in the chroot. Things shouldn’t break unless the classic snap changes, and people making those changes would notice strict mode denials right away (and could propose changes to snapd as appropriate).
I am thinking of the Paradrop project in particular. One of the more complicated use cases is launching a Docker container, creating a virtual wireless interface, configuring the interface, then assigning it to the namespace of the container. I really appreciate your offer to help, but I doubt very many other snaps require these capabilities. For myself, I prefer a single command line flag that indicates beware: this snap is dangerous over spending hours trying to debug these kinds of messages:
Feb 27 15:30:46 localhost.localdomain audit[2282]: AVC apparmor=“ALLOWED” operation=“open” profile=“snap.paradrop-daemon.paradrop” name="/sys/fs/cgroup/net_cls,net_prio/docker/166213da8f1f2804a209df5a50a899413f0f7486899dea11de1fb488ea08387a/net_cls.classid" pid=2282 comm=“python2” requested_mask=“wc” denied_mask=“wc” fsuid=0 ouid=0
@elopio We really don’t want to have a large crowd installing unconfined snaps in development mode from arbitrary sources, for multiple reasons:
All of those points look very uncontroversial to me. Personal disagreement is fine, but we need a project policy here, and that one must be sensible.
@lance We would actually like to get that confined if you’re willing to spend a moment with us. It shouldn’t be that hard because some of those are already interfaces in the system. For example, we already have docker-support and we also have network-control interfaces.
Is Docker present inside the snap itself? How is it landing on the Ubuntu Core system?
@niemeyer Sure, I am happy to discuss it more. Perhaps this becomes its own thread as it goes off-topic a bit. Currently, we are using the Docker snap and connecting the network-control interface among others. I suppose we might eliminate some problems if we install Docker insider our own snap, but then we would probably need the docker-support interface, right?
Development is not something only developers do. But, as I said, it doesn’t matter because installing strict snaps with --devmode covers my needs. All good.