unexpected errno=13 and disconnected path when trying to open /proc/1/ns/mnt from a unshared mount namespace
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
AppArmor |
Confirmed
|
Undecided
|
Unassigned | ||
linux (Ubuntu) |
Incomplete
|
Undecided
|
Unassigned | ||
Xenial |
Fix Released
|
Undecided
|
Unassigned | ||
Yakkety |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
This bug is based on a discussion with jjohansen on IRC.
While working on a feature for snapd (https:/
The kernel log shows something interesting. The full log is available here: http://
Jan 12 23:16:43 autopkgtest kernel: [ 498.616822] audit: type=1400 audit(148425940
The code that triggers this is reproduced below (also visible here https:/
+void sc_reassociate_
+{
+ int init_mnt_fd __attribute__ ((cleanup(
+ int self_mnt_fd __attribute__ ((cleanup(
+
+ debug("checking if the current process shares mount namespace"
+ "with the init process");
+
+ init_mnt_fd = open("/
+ 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("/
+ 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(
+ die("cannot perform readlinkat() on the mount namespace file "
+ "descriptor of the init process");
+ }
+ memset(self_buf, 0, sizeof self_buf);
+ if (readlinkat(
+ 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(
+ init_mnt_fd_real = open("/
+ if (init_mnt_fd_real < 0) {
+ die("cannot open mount namespace of the init process");
+ }
+ if (setns(
+ die("cannot re-associate the mount namespace with the init process");
+ }
+ } else {
+ debug("
+ }
+}
The specific part that causes the error is:
+ init_mnt_fd_real = open("/
The call to open returns -1 and errno set to 13 (EACCES) despite using attach_
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_
I can reproduce this issue each time by running:
spread -debug -v qemu:ubuntu-
Against the code in this pull request:
https:/
Which is git://github.
Appropriate qemu images can be made using instructions from:
https:/
I'm also happy to try any test kernels as I can easily run those.
Changed in linux (Ubuntu Yakkety): | |
status: | New → Fix Committed |
Changed in linux (Ubuntu Xenial): | |
status: | New → Fix Committed |
tags: |
added: verification-done-xenial verification-done-yakkety removed: verification-needed-xenial verification-needed-yakkety |
Changed in linux (Ubuntu Yakkety): | |
status: | Fix Released → Triaged |
Changed in linux (Ubuntu Xenial): | |
status: | Triaged → Fix Committed |
Please forgive me for making a mistake above:
The call to open returns -1 and errno set to 13 (EACCES) despite using attach_ disconnected.
This should read:
The call to open returns -1 and errno set to 13 (EACCES) despite using *complain* mode.