[snap] chromium-browser snap cannot upload files outside ~

Also I cannot _download_ files. In the dpkg installation, they were saved to /tmp and could be opened with the appropriate helper program (e.g., Evince). Now I see the download in the bottom of the browser bar, but the file will not open (clicks are ignored). chrome://downloads/ displays them, but again I cannot open them. *Show in folder* silently does nothing. They downloads are not in ~/Downloads/ or anywhere else I can identify.

Worked around by going into chrome://settings/downloads and changing the default download location to ~/Downloads. This works, though now I have to set up a script to delete old downloads—I cannot rely on the system’s built-in behavior of clearing /tmp after restarts.

As annoying as it may seem, this is a feature of the snap confinement, for improved security (the app isn't allowed to see files on the host system, except for non-hidden files and folders under $HOME and /mnt and /media (if the removable-media interface is connected).

This will be addressed in the future using portals, but the implementation isn't ready yet (see https://bugs.chromium.org/p/chromium/issues/detail?id=885292).

For your downloads, may I suggest a tmpfs mounted somewhere under $HOME ? I think this would achieve what you're after.

I'm marking this bug invalid as confinement is working as intended, despite the limitations this induces.

Ah finally figure out the source of this brokenness ....

I'm also suffering from this - for 15+ years now my home directory has largely consisted of symbolic links to directories in other mounted file systems (not mounted under /mnt)

I can't upload PCB gerber files to get PCBs made, I can't upload .csv files to the fulfillment service that ships my products to customers - chromium is largely broken, I can't download files into /tmp so I don't have delete them later

I think the problem is at Canonical has decided how home directories should be rather than going out and find out how they actually are - it may be "working as intended" but it's still broken

How do we turn this stuff completely off? or at least be able to whitelist paths rather than this nanny-state crap

I'm afraid I do have to add my voice to this particular complaint as most packages I install with snap seem to have fundamental problems accessing the file system however it's configured with multiple mount points, sim links etc. I've already removed many snap apps and reinstalled with apt which is much more reliable. Not being able to find a file path in Chromium or even be able to type in the path when you want to upload a file is a bit ridiculous to be honest.

At least in Firefox you can use Ctrl + L to access a location

> I can't download files into /tmp so I don't have delete them later

/tmp in the chromium snap is mapped to /tmp/snap.chromium/tmp, so files downloaded there won't be persistent across reboots.

Those who use Veracrypt or similar mounted drives - good luck trying to access those files from Chromium!

I'm not familiar with Veracrypt, but according to their documentation¹, it is possible to mount encrypted volumes as removable drives, which presumably would be mounted under /mnt or /media, and those can be accessed using the removable-media interface².

¹ https://www.veracrypt.fr/en/Removable%20Medium%20Volume.html
² https://snapcraft.io/docs/removable-media-interface

I'm noting that nearly a year after this has been reported there is still no fix and no workaround.
It may be marked as *invalid* because it is a *feature* but there is no way to turn that feature off and get my work done.

Please reopen and put a control to disable this mal-feature on the urgent to do list.

<rage mode>

This affects me too after upgrading from 18.04 LTS to 20.04 and I fint it COMPLETELY UNACCEPTABLE.

The use of symlinks from /home to data on larger drives (which are shared between windows and linux systems, and not unix FS) is industry standard since over 30 years and this regression is atrocious. I will remove the snap and install the .DEB until it is resolved. My root disk is too small for the files i need to upload so a symlink to the storage drive which is permanently mounted in fstab under /datasjoe is necessary. The implication you have also broken access to removable media by default is likewise idiocy, any user is right in assuming he/she can acess theyir usb drves anywhere in their desktop system. Think again.

</rage mode>

please? I dont want to have to give up ubuntu after 11 years of daily driving it.

As lame as such comments may appear:

The level of suffering on my side is large enough to add that I too am really irritated by this “feature”. It is a significant obstacle in my daily workflow, and any workaround must not be necessary in the first place. We’ve been living with browsers with (user!) access to the whole filesystem for decades without worrying. Besides, the software still comes from a trusted source.

Here I am, trying to use headless Chromium to render screenshots, and on
Ubuntu 20.04, I find that Chromium is simply not writing to `/tmp`. So,
let me add my voice to the chorus of those flummoxed and frustrated by
this decision.

The easiest way to get around this appears to be to install Chromium
from an unofficial PPA. Ironic, given the intent of "improved security".
As they say, security at the expense of usability comes at the expense
of security.

Hi Olivier (or whoever knows about Chromium), I see that the upstream support for the XDG file selector portal landed somewhere in July this year (https://chromium-review.googlesource.com/c/chromium/src/+/2992214/), but I cannot find information on which Chromium version contains this change.

I'm using chromium from the "latest/stable" channel (96.0.4664.45), and according to a quick test with d-feet, it appears that the FileChooser method is working on my desktop -- but I still cannot upload files stored in /tmp.

After some good hints from Oliver I did some investigation on this issue. Indeed it looks like the chromium snap is doing the right thing: it first checks if the D-Bus service "org.freedesktop.portal.Desktop" is running (if not, it falls back on calling ListActivatableNames, which is not ideal because this currently gets blocked by AppArmor -- but in my tests the call to NameHasOwner works, so this path is not even taken), and then it checks that the "version" property on the "org.freedesktop.portal.FileChooser" interface is at least 3.

Unfortunately, on my Focal system this version is 2 (version 3 was released just about at the time when Focal was: https://github.com/flatpak/xdg-desktop-portal/commit/00b28db5ca45bcbdfea0ddfff8447a3f8836bfd9), so the portal dialog is not used.

I'm reopening this bug in light of Alberto's recent findings.

Alberto, it would be useful if you could test this on a more recent system, e.g. impish, and report whether with a new enough version of the portal, opening/saving files anywhere on the filesystem works.

Hi Olivier! I tried on hirsute, and it's working :-)

Then I guess that the only series still supported by Canonical and affected by this bug are the LTSes.

I added all of them to this bug, but it may be taht we don't have to worry about xenial and bionic, since one can use the deb package there.

Thanks for testing, and for the feedback Alberto.
Let's say it's okay to assume that the portal is already running and accessible through the bus (i.e. the ListActivatableNames path won't be taken − there's an upstream bug to track this: https://bugs.chromium.org/p/chromium/issues/detail?id=1278336).

Then indeed the problem remains for xenial, bionic and focal where the XDG desktop portal isn't new enough. But it's unlikely that a new major version of the portal can be backported to these release with a regular SRU, so it looks like a "Won't Fix" status to me, what do you think?

Hi Olivier, let me take some time to investigate what are the changes to the next major version, because if we are lucky and they are small and safe, we could really think about a SRU. At least for 20.04, which is going to be supported for quite a few years from now.

Also, let's keep in mind that Firefox and other apps will also be affected by this (version 3 of the XDG spec add the "directory mode" to the file chooser, which is likely useful to many applications).

Here are the changes we'd need to backport to Focal in order to fix this bug there:

To package xdg-desktop-portal-gtk:
- https://github.com/flatpak/xdg-desktop-portal-gtk/commit/920afdde7afc023e77ecfeb4e174cb42f22cbfe3

To package xdg-desktop-portal:
- https://github.com/flatpak/xdg-desktop-portal/commit/c616b491fe0ac67f78a14bcaf0d3a150bfadfd82
- https://github.com/flatpak/xdg-desktop-portal/commit/00b28db5ca45bcbdfea0ddfff8447a3f8836bfd9
- https://github.com/flatpak/xdg-desktop-portal/commit/80915e6a5bd9466c17d46011bf6d16b4a57118a0
- https://github.com/flatpak/xdg-desktop-portal/commit/470cc132f4993ebbc514eaef6ad7af8000c388ba

I'll check with the Release team to see how they feel about this.

Speaking from a desktop perspective those changes seem safe enough if you confirmed they are resolving the chromium issue? There as some more fixes in newer version like https://github.com/flatpak/xdg-desktop-portal/commit/48a981ee but unsure if that's required.

Note that usually we would probably prefer updating to a newer version but 1.7 which is the first including those changes also bump the pipewire requirement to 0.3 which isn't in focal and includes some other rewrite which would probably be more risky to SRU

Status changed to 'Confirmed' because the bug affects multiple users.