Okay. So to unbreak the confinement in the mean time, one can do this:
(1) Find an include that is not owned by snap (because an update will
likely break things again):
# sed -e '/#include/!d;s/.*#include //' \
/var/lib/snapd/apparmor/profiles/snap.chromium.chromium |
sort -u
<abstractions/base>
<abstractions/consoles>
<abstractions/cups-client>
..
<abstractions/ssl_certs>
<abstractions/X>
<tunables/global>
I choose abstractions/X.
(2) Edit that file -- /etc/apparmor.d/abstractions/X -- and place this
at the end:
# Give back read permissions to ALL files, not just user-owned-files
# Added here (it's included by /var/lib/snapd/apparmor/profiles/*)
# because snap likely won't give me a proper local hook to fix
# broken rules (LP: #1987945)
@{HOME}/[^.]** r,
(3) systemctl restart snapd.apparmor.service
Now you have succesfully "compromised security" on your system: all
apparmor profiles that include <abstractions/X> will get read powers in
your homedir. But your most used tool -- the browser -- is usable again.
--
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 in $HOME
Status in chromium-browser package in Ubuntu:
Confirmed
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
