[snap] chromium does not read root-owned files in $HOME

[Walter]

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.)

[Olivier Tilloy (osomon)]

Thanks for the report Walter. This hasn't fallen on deaf ears. Reading and uploading a file to which you have read permissions in your home directory is definitely something that's expected to work, and if it doesn't it needs to be investigated and fixed.

Can you try the following?

    snap run --shell chromium
    stat $SNAP_REAL_HOME/Junk/rode_muur_root.jpg
    exit

and share the output here?

Is there anything "exotic" (i.e. non-default options) about your home directory?

[Walter (wdoekes)]

Outside snap:

--

$ cmp Junk/rode_muur.jpg Junk/rode_muur_root.jpg
(no output, files are equal)

--

Inside Chromium snap confinement:

--

[snap]$ cmp Junk/rode_muur.jpg Junk/rode_muur_root.jpg
cmp: Junk/rode_muur_root.jpg: Permission denied

--

[snap]$ stat Junk/rode_muur_root.jpg
  File: Junk/rode_muur_root.jpg
  Size: 64773 Blocks: 128 IO Block: 4096 regular file
Device: fd01h/64769d Inode: 11017147 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2022-08-29 21:39:39.249598358 +0200
Modify: 2022-08-27 18:08:23.703069049 +0200
Change: 2022-08-27 18:08:28.839077299 +0200
 Birth: -

--

[snap]$ diff -pu <(stat Junk/rode_muur.jpg) <(stat Junk/rode_muur_root.jpg)
--- /dev/fd/63 2022-08-29 21:42:55.718167721 +0200
+++ /dev/fd/62 2022-08-29 21:42:55.722167732 +0200
@@ -1,8 +1,8 @@
- File: Junk/rode_muur.jpg
+ File: Junk/rode_muur_root.jpg
   Size: 64773 Blocks: 128 IO Block: 4096 regular file
-Device: fd01h/64769d Inode: 11017139 Links: 1
-Access: (0664/-rw-rw-r--) Uid: ( 1000/ walter) Gid: ( 1000/ walter)
-Access: 2022-08-29 21:39:47.185621370 +0200
-Modify: 2022-08-27 18:08:17.979060004 +0200
-Change: 2022-08-27 18:08:17.979060004 +0200
+Device: fd01h/64769d Inode: 11017147 Links: 1
+Access: (0664/-rw-rw-r--) Uid: ( 0/ root) Gid: ( 0/ root)
+Access: 2022-08-29 21:39:39.249598358 +0200
+Modify: 2022-08-27 18:08:23.703069049 +0200
+Change: 2022-08-27 18:08:28.839077299 +0200
  Birth: -

--

Can't tell from stat that I'm disallowed. In fact, if I have group read perms, I still cannot read it:

--

[snap]$ id
uid=1000(walter) gid=1000(walter) groups=1000(walter),4(adm),20(dialout),24(cdrom),27(sudo),29(audio),30(dip),46(plugdev),113(lpadmin),128(sambashare),139(docker)

--

[snap]$ ls -l Junk/rode_muur*
-rw-rw-r-- 1 walter walter 64773 aug 27 18:08 Junk/rode_muur.jpg
-rw-rw-r-- 1 root root 64773 aug 27 18:08 Junk/rode_muur_root.jpg
-rw-rw-r-- 1 root walter 64773 aug 27 18:08 Junk/rode_muur_rootuser.jpg

--

[snap]$ cmp Junk/rode_muur.jpg Junk/rode_muur_rootuser.jpg
cmp: Junk/rode_muur_rootuser.jpg: Permission denied

--

[snap]$ stat Junk/rode_muur_rootuser.jpg
  File: Junk/rode_muur_rootuser.jpg
  Size: 64773 Blocks: 128 IO Block: 4096 regular file
Device: fd01h/64769d Inode: 11017142 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 0/ root) Gid: ( 1000/ walter)
Access: 2022-08-29 21:39:39.249598358 +0200
Modify: 2022-08-27 18:08:23.703069049 +0200
Change: 2022-08-29 21:47:17.446925673 +0200
 Birth: -

--

FYI, /etc has different confinement, where root files _can_ be read:

--

[snap]$ ls -lda /etc
drwxr-xr-x 179 root root 12288 aug 28 16:49 /etc

--

[snap]$ ls /etc/
ls: cannot open directory '/etc/': Permission denied

--

[snap]$ ls -l /etc/hostname
-rw-r--r-- 1 root root 20 jun 16 2020 /etc/hostname

--

[snap]$ cat /etc/hostname
walter-tretton.kiwi

--

Versions:

--

$ snap version
snap 2.56.2+22.04ubuntu1
snapd 2.56.2+22.04ubuntu1
series 16
ubuntu 22.04
kernel 5.15.0-41-generic

--

$ snap list | grep chrom
chromium 104.0.5112.79 2051 latest/stable canonical** -

--

$ na...

[Olivier Tilloy (osomon)]

That's probably because by default the home interface doesn't allow access to files not owned by $USER.

The interface has a "read" attribute that, when set to "all", allows this behaviour. See https://snapcraft.io/docs/home-interface for details (I wasn't aware of this subtlety of the interface until now). Setting that attribute makes the interface not autoconnect by default, though.

[Olivier Tilloy (osomon)]

Arguably, the case for files not owned by the user in their home directory is not very widespread.

[Walter (wdoekes)]

"Arguably"

Yes, I will argue with you there.

- How about tcpdump writing as the tcpdump user+group in my homedir? I can read them, delete them, but not send them to someone using the browser?

- Me getting files as root, because I need special powers (for vpn, network, usb, ...)? mv(1)/cp(1) will not chown by default.

- Having read-only files in a homedir, administered by root?

If the argument is that no one is ever root to do user-stuff on their desktop, then you'll likely lose the power-users.

[Walter (wdoekes)]

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.

[Olivier Tilloy (osomon)]

> Yes, I will argue with you there.

Don't get me wrong, yours is a totally valid use case. I'm just saying it's perhaps not that common, and perhaps doesn't justify the use of the "read: all" attribute on the home interface, which would mean that the interface wouldn't be auto-connected, which would affect many more users.

With the current situation, it's a trade-off, and as such it doesn't address all the use cases perfectly.

Now, I'll inquire with the snap security team whether using that attribute and requesting auto-connection would be acceptable, and if it is we'll make the change so that you don't have to tamper with system-wide apparmor abstractions to get what you need.

[Olivier Tilloy (osomon)]

There are precedents for this use case, apparently: https://forum.snapcraft.io/t/interface-auto-connect-request-for-the-universal-update-utility-snap-home-read-all/23125.

[Olivier Tilloy (osomon)]

Let's see what the snapd folks have to say about it: https://forum.snapcraft.io/t/auto-connecting-the-home-interface-with-read-all-for-a-browser-snap/31525

[Walter (wdoekes)]

Thanks for the forward!

[Nathan Teodosio (nteodosio)]

I can also reproduce this issue in Firefox (stable channel, version 104.0.2-1), can you?

[Walter (wdoekes)]

I have purged all of snap from my machines, so I cannot reproduce. But I'm 100% positive Firefox suffers from exactly the same issues.

The snap team decided that apparmoring applications was the way forward, even though this causes inexplicable breakage for some people who are just trying to get work done. The "as a community, we force people to adapt to far worse workarounds than running chown on files for much more common usecases" quote from James-Carrol, on the snapcraft forum is telling.

:shrug:

[Nathan Teodosio (nteodosio)]

Sorry but this should be marked "Won't fix" as per the Snapcraft team response on #9.

[Walter (wdoekes)]

I'm not sorry. The change to Mint packages was the best thing I did to my desktop in a long time.
This has saved me from so much frustration already.

A recipe that works: https://www.osso.nl/blog/chromium-browser-without-ubuntu-snap-linux-mint/

Respectfully,
Walter