Hi,
I would like to ask classic confinement for the curl snap.
The reason is that many tools assume that curl can write anywhere, which is not the case using the current strict confinement. And this is causing confusion for users, see e.g. https://github.com/woutervb/snap-curl/issues/2
The code for the snap can be found here: https://github.com/woutervb/snap-curl
The snap is located here: https://snapcraft.io/curl
@alexmurray please see my request here
As per the Process for reviewing classic confinement snaps, the requirement to write to arbitrary locations on the file-system is not sufficient for granting classic confinement override for a snap. Plugging home (and optionally removable-media) provides access to the vast majority of locations that users will require and using strict confinement provides additional benefits such as a stable runtime environment and isolation etc. As such, unfortunately I don’t think it is appropriate to grant classic confinement for curl.
Hi Alex,
Thanks for the response, looking at both interfaces, it is not clear to me, how this would help with the npm usecase, e.g. the tool from: https://github.com/nvm-sh/nvm
I can add at least the home & removable-media interfaces, but that won’t give access to hidden files / directories under the user home directory. Is there an interface that can be used for this?
Would the personal-files interface with write to ~/.* allow this, assuming that this would be acceptable?
Looking to the npm installation script it will write to either .nvm or .config/nvm (the latter if the XDG_* variables are defined.
Another script I found (and that is probably used as well) is hosted on https://rustup.rs/.
This will also fail if only the curl snap is installed, as it will attempt to write in /tmp/, which is also not allowed by default, and afaik there is no interface available for that.
Open to suggestions to get this fixed, as it will cause confusion with users that use the snap and suddenly have problems with random tools.
This is false, strict snaps can write to /tmp, they just happen to write to a snap private /tmp that is not the exact same as the host’s /tmp, but this is easily handled because /tmp for the snap ends up being a sub-dir of the host’s /tmp.
Also keep in mind that classic confinement means that the curl snap would not be usable on Ubuntu Core. I say this because I have my own unlisted curl snap that is strict that I built just for my own uses on Ubuntu Core and lots of random folks have accidentally found it and started using it on Ubuntu Core (which is unfortunate since I don’t maintain it very much /o\ but it is unlisted so 
). All that is to say, there is definitely a demand for a well maintained strictly confined curl snap on Ubuntu Core, even if it is not 100% usable in classic. But classic still has curl as a deb easily available.
This is non trivial for an unaware user / scripts as they assume that the mapping of directories is the same. I.E. if they write to /tmp they expect a file to be present in /tmp and not in /tmp/<subfolder>
I was not aware about this need, and think that this might be a case that we need 2 tracks, 1 with classic confinement for ubuntu core and 1 with classic confinement for non core usage. Is this something worth to work on?
I’d say this is a typical use-case of maintaining separate tracks of the snap.
I would certainly be +1 to having a strict and a classic track if curl is granted classic confinement.
Hey @woutervb,
As @alexmurray this request is not falling under the supported categories for granting classic confinement.
Unfortunately no, the personal-files interface is typically used to provide read-only access to top-level hidden data directories within a user’s real home directory, in order to support importing data from existing applications where the snap is the clear owner of the target directory. But I think you could request the use of personal-files with write access to each of the tools which usually depend on curl. Do you think that works? If granted, it probably will need manual connection since curl will not be the clear owner of such directories.
For other directories, you could explore system-files or even system-backup
@woutervb - ping, this request cannot proceed without the requested information.
Hi @pfsmorigo,
I tried / examined the suggested interfaces, but they don’t allow the access that curl needs. I.e. access to non-mapped /tmp directory. For example to have the output being piped, or just that an installer script writes it’s data there.
And also arbitrary access to $USER directory, as there are also installers using curl, that write to ~/.* files such as the above mentioned npm script.
I saw that there once was talk about a ‘classic’ interface, that sounds like a solutions, but I think it does not exists.
FYI I also started a thread to get a separation between a confined and a non-confined version, see New track (classic) request for the curl snap
Hey @woutervb,
Unfortunately we cannot proceed with this request. As stated above, the justification provided is not enough and it does not fit under any of the existing supported categories to grant classic confinement.
Apologize for the inconveniences.
The state of affairs we’re left with as a result of this refusal 3 years ago is a farce. I just did a fresh install of Ubuntu, and when I first needed to use curl, Ubuntu recommends that I install Wouter’s Snap:
mark@fractal:~$ curl
Command 'curl' not found, but can be installed with:
sudo snap install curl # version 8.1.2, or
sudo apt install curl # version 7.81.0-1ubuntu1.14
See 'snap info curl' for additional versions.
So I did. But of course, it’s broken, because curl has a feature (--output) that takes a file path to write to, and any such feature fundamentally does not and cannot work inside a Snap with strict confinement because such a Snap cannot be given the ability to write to arbitrary files. The only fix is to uninstall the curl Snap and install a non-broken version with apt-get or via some other means.
But that means the curl Snap is a trap for end users like me, and is making the world worse just by existing. The Stack Overflow question that alerted me to the cause of my permissions error, https://stackoverflow.com/q/67541374/1709587, has over 50000 views, which - given Stack Overflow tries to be conservative about not double-counting unique viewers in its view counts - is probably a lower bound for how many people this Snap has tripped up. Plenty of other users doubtless found their solution without viewing that particular question; the total number harmed is almost certainly at least in the hundreds of thousands. In total, many man-years, maybe entire human lifetimes, must have been wasted debugging issues caused by this Snap alone.
(More generally, the refusal here seems to imply that any application with a feature that allows writing to files at user-specified paths simply cannot be distributed in a fully-working state by Snap - at least not unless it coincidentally meets some other criterion that qualifies it for classic confinement. This is not an obvious fact about Snap until you encounter a bug like this one, and it’s a design decision I find difficult to make sense of! The ability to grant this access exists, and some applications already get it, but as a matter of policy certain applications like curl aren’t allowed it and so distributing non-broken versions of them via Snapcraft is simply forbidden? TBH, that simply seems like a dumb policy…)
If that’s what Canonical wants to insist on, fine - but in that case, is there at least something that can be done to protect users from breaking their systems by installing the (unfixably) broken curl Snap that Wouter has already published? It’d be helpful to unpublish the Snap and also prevent Snaps from ever being suggested as a way to provide the curl executable if, as a matter of policy, it’s forbidden for any such Snaps to ever actually work.