Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
interfaces/apparmor: allow reading from ecryptfs #2837
b0242ba
6e0f6fd
ad1413a
d22ffc4
c3ad251
fc04692
79a5613
e8d746a
582af4b
0daedb6
a392719
f7e780a
| @@ -408,6 +408,21 @@ var defaultTemplate = ` | ||
| } | ||
| ` | ||
| +// encryptedHomeTrySnippet contains apparmor snippet that allows for "snap try" | ||
| +// operations to work even if the home directory is encrypted. | ||
| +var encryptedHomeTrySnippet = ` | ||
| + # Workaround policy added by 'snap try' to support ecryptfs and | ||
| + # /var/lib/snapd/snaps/<name>_xN.snap pointing inside user's directory | ||
| + capability dac_override, | ||
| + capability dac_read_search, | ||
| + # encrypted ~/.Private and old-style encrypted $HOME | ||
| + @{HOME}/.Private/ r, | ||
| + @{HOME}/.Private/** mrixwlk, | ||
| + # new-style encrypted $HOME | ||
| + @{HOMEDIRS}/.ecryptfs/*/.Private/ r, | ||
| + @{HOMEDIRS}/.ecryptfs/*/.Private/** mrixwlk, | ||
kyrofa
Member
|
||
| +` | ||
| + | ||
| // classicTemplate contains apparmor template used for snaps with classic | ||
| // confinement. This template was Designed by jdstrand: | ||
| // https://github.com/snapcore/snapd/pull/2366#discussion_r90101320 | ||
Looking at the bug, it has:
This output appears truncated, but this path is important:
/home/.ecryptfs/kyrofa/.Private/ECRYPTFS_FNEK_ENCRYPTED.FBaOD17IzZ9EsEQj239cjqBho2j-3yXXfzRq3GXkhDoVeoqkJlBFyivegA--/ECRYPTFS. /etc/apparmor.d/abstractions/base has a rule that matches this path:Since you said that this is the configure hook, we know that the configure hook runs as root, we see that the rules added to this PR effectively only remove 'owner', and we see that the root process is trying to access encrypted files in /home/.ecryptfs/kyrofa/.Private/.... I'm not sure of the cause, but it seems like the snap in the bug is trying to have a 'daemon' access files in the user's directory. We don't allow non-owner match in the default policy or the home interface now, and we shouldn't allow that in the ecryptfs policy.
@kyrofa - I expect this configure hook will fail on non-encrypted HOME systems. Does it? If not, can you strace the process and see what file it is accessing?
-1 as is without more information.