This bug is missing log files that will aid in diagnosing the problem.
>From a terminal window please run:
apport-collect 1656121
and then change the status of the bug to 'Confirmed'.
If, due to the nature of the issue you have encountered, you are unable
to run this command, please add a comment stating that fact and change
the bug status to 'Confirmed'.
This change has been made by an automated script, maintained by the
Ubuntu Kernel Team.
** Changed in: linux (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1656121
Title:
unexpected errno=13 and disconnected path when trying to open
/proc/1/ns/mnt from a unshared mount namespace
Status in AppArmor:
Confirmed
Status in linux package in Ubuntu:
Incomplete
Status in linux source package in Xenial:
Fix Committed
Status in linux source package in Yakkety:
Fix Committed
Bug description:
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1656121/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
