[snap] Permission denied on Private encrypted folder

Bug #1848919 reported by Alex N. on 2019-10-20
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
AppArmor
Low
Jamie Strandboge
snapd
Low
Jamie Strandboge
chromium-browser (Ubuntu)
Low
Unassigned
snapd (Ubuntu)
Low
Unassigned

Bug Description

When accessing the Private (/home/username/Private, Encrypted Directory) folder (e.g. via "Link save as...") it shows "Could not read contents of Private, Error opening directory ...: Permission denied"

Package: chromium-browser
Version: 77.0.3865.120-0ubuntu1~snap1

Alex N. (a-nox) on 2019-10-20
description: updated
Olivier Tilloy (osomon) wrote :

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.

Changed in chromium-browser (Ubuntu):
status: New → Confirmed
summary: - [snap] Permission denied on Private folder
+ [snap] Permission denied on Private encrypted folder
Changed in chromium-browser (Ubuntu):
importance: Undecided → Low
Jamie Strandboge (jdstrand) wrote :

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?

Olivier Tilloy (osomon) wrote :

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

Jamie Strandboge (jdstrand) wrote :

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

Olivier Tilloy (osomon) wrote :

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)

Jamie Strandboge (jdstrand) wrote :

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

Changed in snapd (Ubuntu):
assignee: nobody → Jamie Strandboge (jdstrand)
importance: Undecided → Low
status: New → Triaged
Olivier Tilloy (osomon) wrote :

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.

Changed in chromium-browser (Ubuntu):
status: Confirmed → Invalid
Changed in snapd (Ubuntu):
status: Triaged → In Progress
Changed in apparmor:
status: New → Triaged
importance: Undecided → Low
assignee: nobody → Jamie Strandboge (jdstrand)
Jamie Strandboge (jdstrand) wrote :
Changed in snapd (Ubuntu):
assignee: Jamie Strandboge (jdstrand) → nobody
Changed in snapd:
importance: Undecided → Low
assignee: nobody → Jamie Strandboge (jdstrand)
milestone: none → 2.42.3
Changed in snapd (Ubuntu):
status: In Progress → Triaged
Changed in snapd:
status: New → In Progress
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers