@abeato and myself are trying to test out snap-confine to make sure that it is working on a 3.4 kernel with both apparmor and seccomp turned off in the kernel’s config since confinement just isn’t going to work on such an old kernel. We’re using the updated version of snap-confine from this PR: https://github.com/snapcore/snapd/pull/3243
What we’re seeing is the following output when running hello-world from the hello-world snap:
test@localhost:~$ /snap/bin/hello-world cannot open mount namespace of the init process (O_PATH): No such file or directory
This seems to be the line that prints this error but am wondering if anyone has any thoughts on what we might be missing from either our kernel config or how we’re mounting the filesystem for the device target?
The second issue is most likely caused by the use of a 3.4-based kernel (patched) that doesn’t support fchdir(2) on a file descriptor obtained with open(2) using the O_PATH flag. We are confirming it now.
$ hello-world
cannot bind-mount the mount namespace file /proc/1602/ns/mnt → hello-world.mnt: Invalid argument
support process for mount namespace capture exited abnormally
I think there may be a separate patch that relates to using bind mounts to capture namespace objects. I really think that at this stage you should have a kernel person look at that though.
You can also experiment with simple tools like mount and nsenter to see if this part of the kernel works. If it works with nsenter let me know and we can look for anything that snap-confine can learn and do differently.
Ah, indeed. I’m aware of this but I forgot to mention (this is why snap-confine has the extra logic to fork and then capture the mount namespace of a process that unshared).
Could we get a patch for snap-confine to allow for a system to disable seccomp and still have snap-confine be ok with this? This would be the equivalent patch to the one that @zyga-snapd already did for us when apparmor is disabled.