I do not, but it’s more than just that. Assuming that sendmsg was fixed, we’d still need the conditional policy apparmor network rules. Assuming we had fine-grained network mediation to the point of ‘network nfs’ (note, this is not something that fine-grained network mediation phase 1 or phase 2 is meant to specifically address so I’m speaking hypothetically here), we still would only want to have those rules as conditional policy.
Only if there is something like “if file is on nfs then don’t check network stuff and instead only check the file path/inode label” could we get rid of the conditional policy. That would require a path check in sendmsg which is not something seccomp is designed to do and my guess is this sort of check in the LSMs (ie AppArmor, SELinux, Tomoyo) would not be upstreamable. For a more concrete answer, you’d need someone from the kernel team, John or Tyler to comment, but I think considering changing the kernel in this way is largely academic.
Thank you for responding. I think this is unfortunate (kernel implementation details leaning) but it is what it is. Thank you for the detailed response.
Hi! I’m in this situation: I need to access files on the system that are on NFS shares from some of my snaps, like keepassxc and vlc that have the network plug specified: can I use any workaround?
OK, I’m a little bit sleep today: the snaps are not seeing the mount because it’s not in the home directory: all the snap sees is a fake root directory…if I the NFS share is mounted in my home directory, snaps with the network plug would be able to access it.
@zyga-snapd, between this topic and Snapd vs upstream kernel vs apparmor I’m beginning to think we want to create a .d directory for snap-confine to #include so we can drop profile snippets in it. Eg:
snap-confine profile has #include </var/lib/snapd/apparmor/snap-confine.d>
snapd detects NFS /home (or we use the snap config core set home-nfs idea), creates /var/lib/snapd/apparmor/snap-confine.d/home-nfs with network inet, network inet6, and reloads the snap-confine profile
snapd adds network inet, network inet6, to all generated snapd apparmor policy if detects NFS /home (or we use the snap config core set home-nfs idea)
snapd is forcing devmode (eg, due to lack of apparmor requirements) and create /var/li/snapd/apparmor/snap-confine.d/apparmor-forced-devmode with /usr/lib/snapd/snap-exec uxr, (for the other topic) and reloads the snap-confine profile
I think this problem is understood enough for someone to work on this.
@mwhudson - it could be under /run, but that would complicate things because it needs to exist when the profile is loaded. The apparmor unit will start before snapd on boot and then the snap-confine profile would fail to load.
An advantage of having it under /var/lib/snapd/apparmor/snapd-confine.d is that this directory can be shared between re-execs and therefore users can more easily apply workaround policy if they need to. For example, this issue is more painful for people now because it can’t be worked around any more since the re-exec’d snapd may use a profile that is in the readonly snap. Having it in the suggested directory means user changes will be persistent.
I’ve been working on this last week and I think it’s ready for review. I implemented a simple active detection of NFS under /home/ (either fstab or mountinfo must refer to it). When one is detected we inject extra snippets into all application profiles as well as into (and this is a new thing) the profile of snap-confine itself.
I have the same symptoms without using NFS. I am using pbis (used to be Likewise-open) to authenticate with a windows domain server on my linux system.
The process running under profile "/snap/core/3748/usr/lib/snapd/snap-confine (this is a profile used by internal part of snapd itself) tired to access /home/SENSOFT/damann/ for reading (request_mask="r") but reading was denied (denied_mask="r").
What is curious about this is that snap-confine doesn’t need to access one’s home directory. I wonder if any of this is caused by ALL-CAPS home directory.
for me it’s the same. I’d prefer to keep my nfs mounted home but with that I can not use any snap.
In the case of vectr i.e.:
$vectr
$2018/08/15 19:04:34.854496 system_key.go:127: cannot determine nfs usage in generateSystemKey: cannot parse /etc/fstab: open /etc/fstab: permission denied
$2018/08/15 19:04:34.858470 cmd_run.go:708: WARNING: cannot create user data directory: cannot update the 'current' symlink of "/gpfs01/berens/user/slaturnus/snap/vectr/current": symlink 2 /gpfs01/berens/user/slaturnus/snap/vectr/current: operation not supported
$cannot create user data directory: /gpfs01/berens/user/slaturnus/snap/vectr/2: Read-only file system
executing with sudo yields
snap run vectr
mkdir: cannot create directory '/run/user/0': Permission denied
No protocol specified