This bug is based on a discussion with jjohansen on IRC.
While working on a feature for snapd (https://github.com/snapcore/snapd/pull/2624) we came across an unexpected EACCES that only seems to happen when apparmor is in the loop.
The kernel log shows something interesting. The full log is available here: http://paste.ubuntu.com/23789099/
Jan 12 23:16:43 autopkgtest kernel: [ 498.616822] audit: type=1400 audit(1484259403.009:67): apparmor="ALLOWED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="snap.test-snapd-tools.cmd//null-/usr/bin/snap//null-/usr/lib/snapd/snap-confine" name="" pid=25299 comm="snap-confine" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
The code that triggers this is reproduced below (also visible here https://github.com/snapcore/snapd/pull/2624/files)
+void sc_reassociate_with_pid1_mount_ns()
+{
+ int init_mnt_fd __attribute__ ((cleanup(sc_cleanup_close))) = -1;
+ int self_mnt_fd __attribute__ ((cleanup(sc_cleanup_close))) = -1;
+
+ debug("checking if the current process shares mount namespace"
+ "with the init process");
+
+ init_mnt_fd = open("/proc/1/ns/mnt",
+ O_RDONLY | O_CLOEXEC | O_NOFOLLOW | O_PATH);
+ if (init_mnt_fd < 0) {
+ die("cannot open mount namespace of the init process (O_PATH)");
+ }
+ self_mnt_fd = open("/proc/self/ns/mnt",
+ O_RDONLY | O_CLOEXEC | O_NOFOLLOW | O_PATH);
+ if (self_mnt_fd < 0) {
+ die("cannot open mount namespace of the current process (O_PATH)");
+ }
+ char init_buf[128], self_buf[128];
+ memset(init_buf, 0, sizeof init_buf);
+ if (readlinkat(init_mnt_fd, "", init_buf, sizeof init_buf) < 0) {
+ die("cannot perform readlinkat() on the mount namespace file "
+ "descriptor of the init process");
+ }
+ memset(self_buf, 0, sizeof self_buf);
+ if (readlinkat(self_mnt_fd, "", self_buf, sizeof self_buf) < 0) {
+ die("cannot perform readlinkat() on the mount namespace file "
+ "descriptor of the current process");
+ }
+ if (memcmp(init_buf, self_buf, sizeof init_buf) != 0) {
+ debug("the current process does not share mount namespace with "
+ "the init process, re-association required");
+ // NOTE: we cannot use O_NOFOLLOW here because that file will always be a
+ // symbolic link. We actually want to open it this way.
+ int init_mnt_fd_real
+ __attribute__ ((cleanup(sc_cleanup_close))) = -1;
+ init_mnt_fd_real = open("/proc/1/ns/mnt", O_RDONLY | O_CLOEXEC);
+ if (init_mnt_fd_real < 0) {
+ die("cannot open mount namespace of the init process");
+ }
+ if (setns(init_mnt_fd_real, CLONE_NEWNS) < 0) {
+ die("cannot re-associate the mount namespace with the init process");
+ }
+ } else {
+ debug("re-associating is not required");
+ }
+}
The specific part that causes the error is:
+ init_mnt_fd_real = open("/proc/1/ns/mnt", O_RDONLY | O_CLOEXEC);
The call to open returns -1 and errno set to 13 (EACCES) despite using attach_disconnected.
The code in question is executed from a seguid root executable that runs under a complain-mode profile (it is started from a process that is already confined with such a profile). All of the profiles are using attach_disconnected.
I can reproduce this issue each time by running:
spread -debug -v qemu:ubuntu-16.04-64:tests/regression/lp-1644439
Against the code in this pull request:
https://github.com/snapcore/snapd/pull/2624
Which is git://github.com/zyga/snapd in the "reassociate-fix" branch
Appropriate qemu images can be made using instructions from:
https://github.com/zyga/spread-qemu-images
I'm also happy to try any test kernels as I can easily run those.
Please forgive me for making a mistake above:
The call to open returns -1 and errno set to 13 (EACCES) despite using attach_
This should read:
The call to open returns -1 and errno set to 13 (EACCES) despite using *complain* mode.