Public bug reported: Today, I literally spent hours trying to figure out why I cound't upload a large file.
Of course I thought the problem was the size of the file. It wasn't. The problem was that Chromium in Snap for some reason is confined so that it can SEE file-owned-by-root.zip, but NOT READ file- owned-by-root.zip. I tried to upload the big file onto a PsiTransfer webpage. And it simply stalled. The apache2 backend reported 400-errors and I got no useful info out of that. Chromium itself reported this in the Networking tab: PATCH https://PSITRANSFER_HOST/path net::ERR_FAILED Which is totally useless. In no way could I expect that the ultimate cause was that the local file was not owned by me. _If I can see the file, and I have read-permissions on it, I expect that I can upload the file._ Another example: $ ls -l ~/Junk/rode_muur* -rw-rw-r-- 1 walter walter 64773 aug 27 18:08 /home/walter/Junk/rode_muur.jpg -rw-rw-r-- 1 root root 64773 aug 27 18:08 /home/walter/Junk/rode_muur_root.jpg Trying to upload rode_muur_root.jpg to e.g. https://www.filestack.com/fileschool/html/html-file-upload-tutorial- example/ yields this error-page: This site can’t be reached The webpage at https://www.filestack.com/fileschool/html/html-file-upload-tutorial-example/fileupload.php might be temporarily down or it may have moved permanently to a new web address. ERR_ACCESS_DENIED That does not tell me that there is a problem with the local file. That looks like a remote problem, am I right? What would be the fix? - Either don't show the file, if you're not letting me access it; - or let me access the file; - or, if that isn't possible, give me a reasonable error message. Having to look in journalctl [1] as root to find out why a client application is misbehaving is just not acceptable. [1] # journalctl -t audit -n1 -o cat AVC apparmor="DENIED" operation="open" profile="snap.chromium.chromium" name="/home/walter/Junk/rode_muur_root.jpg" pid=768825 comm="ThreadPoolForeg" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 (I know that I'll be complaining to deaf ears. You have your reasons for putting all the browsers in snap. But from a user's perspective, this whole snap thing has been One Giant Disappointment. I'm actually considering moving to alternative distros after more than 10 perfectly satisfactory years on Ubuntu.) ** Affects: chromium-browser (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1987945 Title: [snap] chromium does not read root-owned files, but reports useless errors Status in chromium-browser package in Ubuntu: New Bug description: Today, I literally spent hours trying to figure out why I cound't upload a large file. Of course I thought the problem was the size of the file. It wasn't. The problem was that Chromium in Snap for some reason is confined so that it can SEE file-owned-by-root.zip, but NOT READ file- owned-by-root.zip. I tried to upload the big file onto a PsiTransfer webpage. And it simply stalled. The apache2 backend reported 400-errors and I got no useful info out of that. Chromium itself reported this in the Networking tab: PATCH https://PSITRANSFER_HOST/path net::ERR_FAILED Which is totally useless. In no way could I expect that the ultimate cause was that the local file was not owned by me. _If I can see the file, and I have read-permissions on it, I expect that I can upload the file._ Another example: $ ls -l ~/Junk/rode_muur* -rw-rw-r-- 1 walter walter 64773 aug 27 18:08 /home/walter/Junk/rode_muur.jpg -rw-rw-r-- 1 root root 64773 aug 27 18:08 /home/walter/Junk/rode_muur_root.jpg Trying to upload rode_muur_root.jpg to e.g. https://www.filestack.com/fileschool/html/html-file-upload-tutorial- example/ yields this error-page: This site can’t be reached The webpage at https://www.filestack.com/fileschool/html/html-file-upload-tutorial-example/fileupload.php might be temporarily down or it may have moved permanently to a new web address. ERR_ACCESS_DENIED That does not tell me that there is a problem with the local file. That looks like a remote problem, am I right? What would be the fix? - Either don't show the file, if you're not letting me access it; - or let me access the file; - or, if that isn't possible, give me a reasonable error message. Having to look in journalctl [1] as root to find out why a client application is misbehaving is just not acceptable. [1] # journalctl -t audit -n1 -o cat AVC apparmor="DENIED" operation="open" profile="snap.chromium.chromium" name="/home/walter/Junk/rode_muur_root.jpg" pid=768825 comm="ThreadPoolForeg" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 (I know that I'll be complaining to deaf ears. You have your reasons for putting all the browsers in snap. But from a user's perspective, this whole snap thing has been One Giant Disappointment. I'm actually considering moving to alternative distros after more than 10 perfectly satisfactory years on Ubuntu.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1987945/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
