[snap] Permission denied on Private encrypted folder

I can reliably reproduce the issue after creating an encrypted Private directory with ecryptfs-setup-private (see https://help.ubuntu.com/community/EncryptedPrivateDirectory#Setup_Your_Encrypted_Private_Directory).

The problem stems from the fact that the home interface doesn't allow reading/writing to hidden folders in $HOME, and the ~/Private folder is actually backed by encrypted data in ~/.Private.

This is not specific to chromium, other strictly confined snaps using the home interface would be similarly affected.

Interestingly, saving a file to the folder still works, despite the error and the fact that the file dialog is unable to show the contents of the folder.

Encrypted home is typically setup as ~/.Private, not ~/Private and the policy already allows:

  owner @{HOME}/.Private/** mrixwlk,
  owner @{HOMEDIRS}/.ecryptfs/*/.Private/** mrixwlk,

The home interface should already allow ~/Private. What is the denial you see in the logs?

Indeed I can see the rules you mention in /etc/apparmor.d/abstractions/base, which is included by /var/lib/snapd/apparmor/profiles/snap.chromium.chromium.

However I can reliably reproduce the issue, and I'm seeing the following denial:

  AVC apparmor="DENIED" operation="open" profile="snap.chromium.chromium" name="/home/ubuntu/.Private/" pid=11167 comm="pool" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000

Ok, that is a read on /home/ubuntu/.Private/. Is the encrypted home mounted at the time of the denial?

Yes, it is mounted:

ubuntu@bionicvm:~$ mount | grep Private
/home/ubuntu/.Private on /home/ubuntu/Private type ecryptfs (rw,nosuid,nodev,relatime,ecryptfs_fnek_sig=11d8701311f9dc77,ecryptfs_sig=4ca5cd476d88b7cd,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs)

Ok, I'll fix this in the next batch of policy updates for snapd.

Thanks Jamie.
I'll mark the bug invalid for chromium. Even though chromium is visibly affected, the root cause has been identified and is going to be fixed soon.

https://github.com/snapcore/snapd/pull/7779

This bug was fixed in the package apparmor - 2.13.3-7ubuntu4

---------------
apparmor (2.13.3-7ubuntu4) focal; urgency=medium

  * debian/apparmor.service: add /var/lib/snapd/apparmor/profiles to
    RequiresMountsFor since Ubuntu's rc.apparmor.functions looks for it
    (LP: #1871148)
  * libnss-systemd.patch: allow accessing the libnss-systemd VarLink sockets
    and DBus APIs. Patch partially based on work by Simon Deziel.
    (LP: #1796911, LP: #1869024)
  * upstream-mr-424-kerberos-dot-dirs.patch: abstractions/kerberosclient:
    allow reading /etc/krb5.conf.d/
  * upstream-mr-442-gnome-user-themes.patch: gnome abstraction: allow reading
    per-user themes from $XDG_DATA_HOME (Closes: #930031)
  * upstream-mr-443-ecryptfs-dirs.patch: abstractions/base: allow read access
    to top-level ecryptfs directories (LP: #1848919)
  * upstream-mr-445-uuidd-request.patch: abstractions/base: allow read access
    to /run/uuidd/request
  * upstream-mr-464-Mesa_i915_perf_interface.patch: let Mesa check if the
    kernel supports the i915 perf interface. Patch from Debian

 -- Jamie Strandboge <email address hidden> Mon, 06 Apr 2020 17:47:20 +0000