[Kernel-packages] [Bug 1656121] Re: unexpected errno=13 and disconnected path when trying to open /proc/1/ns/mnt from a unshared mount namespace
This bug was fixed in the package linux - 4.8.0-49.52 --- linux (4.8.0-49.52) yakkety; urgency=low * linux: 4.8.0-49.52 -proposed tracker (LP: #1684427) * [Hyper-V] hv: util: move waiting for release to hv_utils_transport itself (LP: #1682561) - Drivers: hv: util: move waiting for release to hv_utils_transport itself linux (4.8.0-48.51) yakkety; urgency=low * linux: 4.8.0-48.51 -proposed tracker (LP: #1682034) * [Hyper-V] hv: vmbus: Raise retry/wait limits in vmbus_post_msg() (LP: #1681893) - Drivers: hv: vmbus: Raise retry/wait limits in vmbus_post_msg() linux (4.8.0-47.50) yakkety; urgency=low * linux: 4.8.0-47.50 -proposed tracker (LP: #1679678) * CVE-2017-6353 - sctp: deny peeloff operation on asocs with threads sleeping on it * CVE-2017-5986 - sctp: avoid BUG_ON on sctp_wait_for_sndbuf * vfat: missing iso8859-1 charset (LP: #1677230) - [Config] NLS_ISO8859_1=y * [Hyper-V] pci-hyperv: Use device serial number as PCI domain (LP: #1667527) - net/mlx4_core: Use cq quota in SRIOV when creating completion EQs * Regression: KVM modules should be on main kernel package (LP: #1678099) - [Config] powerpc: Add kvm-hv and kvm-pr to the generic inclusion list * linux-lts-xenial 4.4.0-63.84~14.04.2 ADT test failure with linux-lts-xenial 4.4.0-63.84~14.04.2 (LP: #1664912) - SAUCE: apparmor: fix link auditing failure due to, uninitialized var * regession tests failing after stackprofile test is run (LP: #1661030) - SAUCE: fix regression with domain change in complain mode * Permission denied and inconsistent behavior in complain mode with 'ip netns list' command (LP: #1648903) - SAUCE: fix regression with domain change in complain mode * unexpected errno=13 and disconnected path when trying to open /proc/1/ns/mnt from a unshared mount namespace (LP: #1656121) - SAUCE: apparmor: null profiles should inherit parent control flags * apparmor refcount leak of profile namespace when removing profiles (LP: #1660849) - SAUCE: apparmor: fix ns ref count link when removing profiles from policy * tor in lxd: apparmor="DENIED" operation="change_onexec" namespace="root//CONTAINERNAME_" profile="unconfined" name="system_tor" (LP: #1648143) - SAUCE: apparmor: Fix no_new_privs blocking change_onexec when using stacked namespaces * apparmor oops in bind_mnt when dev_path lookup fails (LP: #1660840) - SAUCE: apparmor: fix oops in bind_mnt when dev_path lookup fails * apparmor auditing denied access of special apparmor .null fi\ le (LP: #1660836) - SAUCE: apparmor: Don't audit denied access of special apparmor .null file * apparmor label leak when new label is unused (LP: #1660834) - SAUCE: apparmor: fix label leak when new label is unused * apparmor reference count bug in label_merge_insert() (LP: #1660833) - SAUCE: apparmor: fix reference count bug in label_merge_insert() * apparmor's raw_data file in securityfs is sometimes truncated (LP: #1638996) - SAUCE: apparmor: fix replacement race in reading rawdata * unix domain socket cross permission check failing with nested namespaces (LP: #1660832) - SAUCE: apparmor: fix cross ns perm of unix domain sockets * [Hyper-V][Mellanox] net/mlx4_core: Avoid delays during VF driver device shutdown (LP: #1672785) - Revert "net/mlx4_en: Avoid unregister_netdev at shutdown flow" - net/mlx4_core: Avoid delays during VF driver device shutdown * Update ENA driver to 1.1.2 from net-next (LP: #1664312) - net: ena: Remove unnecessary pci_set_drvdata() - net: ena: Fix error return code in ena_device_init() - net: ena: change the return type of ena_set_push_mode() to be void. - net: ena: use setup_timer() and mod_timer() - net/ena: remove ntuple filter support from device feature list - net/ena: fix queues number calculation - net/ena: fix ethtool RSS flow configuration - net/ena: fix RSS default hash configuration - net/ena: fix NULL dereference when removing the driver after device reset failed - net/ena: refactor ena_get_stats64 to be atomic context safe - net/ena: fix potential access to freed memory during device reset - net/ena: use READ_ONCE to access completion descriptors - net/ena: reduce the severity of ena printouts - net/ena: change driver's default timeouts - net/ena: change condition for host attribute configuration - net/ena: update driver version to 1.1.2 * ISST-LTE:pVM:roselp4:ubuntu16.04.2: number of numa_miss and numa_foreign wrong in numastat (LP: #1672953) - mm: fix remote numa hits statistics - mm: get rid of __GFP_OTHER_NODE * Using an NVMe drive causes huge power drain (LP: #1664602) - nvme/scsi: Remove power management support - nvme: Pass pointers, not dma addresses, to nvme_get/set_features() - nvme: introduce struct nvme_request - nvme: Add a quirk mechanis
[Kernel-packages] [Bug 1656121] Re: unexpected errno=13 and disconnected path when trying to open /proc/1/ns/mnt from a unshared mount namespace
This bug was fixed in the package linux - 4.4.0-75.96 --- linux (4.4.0-75.96) xenial; urgency=low * linux: 4.4.0-75.96 -proposed tracker (LP: #1684441) * [Hyper-V] hv: util: move waiting for release to hv_utils_transport itself (LP: #1682561) - Drivers: hv: util: move waiting for release to hv_utils_transport itself linux (4.4.0-74.95) xenial; urgency=low * linux: 4.4.0-74.95 -proposed tracker (LP: #1682041) * [Hyper-V] hv: vmbus: Raise retry/wait limits in vmbus_post_msg() (LP: #1681893) - Drivers: hv: vmbus: Raise retry/wait limits in vmbus_post_msg() linux (4.4.0-73.94) xenial; urgency=low * linux: 4.4.0-73.94 -proposed tracker (LP: #1680416) * CVE-2017-6353 - sctp: deny peeloff operation on asocs with threads sleeping on it * vfat: missing iso8859-1 charset (LP: #1677230) - [Config] NLS_ISO8859_1=y * Regression: KVM modules should be on main kernel package (LP: #1678099) - [Config] powerpc: Add kvm-hv and kvm-pr to the generic inclusion list * linux-lts-xenial 4.4.0-63.84~14.04.2 ADT test failure with linux-lts-xenial 4.4.0-63.84~14.04.2 (LP: #1664912) - SAUCE: apparmor: fix link auditing failure due to, uninitialized var * regession tests failing after stackprofile test is run (LP: #1661030) - SAUCE: fix regression with domain change in complain mode * Permission denied and inconsistent behavior in complain mode with 'ip netns list' command (LP: #1648903) - SAUCE: fix regression with domain change in complain mode * unexpected errno=13 and disconnected path when trying to open /proc/1/ns/mnt from a unshared mount namespace (LP: #1656121) - SAUCE: apparmor: null profiles should inherit parent control flags * apparmor refcount leak of profile namespace when removing profiles (LP: #1660849) - SAUCE: apparmor: fix ns ref count link when removing profiles from policy * tor in lxd: apparmor="DENIED" operation="change_onexec" namespace="root//CONTAINERNAME_" profile="unconfined" name="system_tor" (LP: #1648143) - SAUCE: apparmor: Fix no_new_privs blocking change_onexec when using stacked namespaces * apparmor oops in bind_mnt when dev_path lookup fails (LP: #1660840) - SAUCE: apparmor: fix oops in bind_mnt when dev_path lookup fails * apparmor auditing denied access of special apparmor .null fi\ le (LP: #1660836) - SAUCE: apparmor: Don't audit denied access of special apparmor .null file * apparmor label leak when new label is unused (LP: #1660834) - SAUCE: apparmor: fix label leak when new label is unused * apparmor reference count bug in label_merge_insert() (LP: #1660833) - SAUCE: apparmor: fix reference count bug in label_merge_insert() * apparmor's raw_data file in securityfs is sometimes truncated (LP: #1638996) - SAUCE: apparmor: fix replacement race in reading rawdata * unix domain socket cross permission check failing with nested namespaces (LP: #1660832) - SAUCE: apparmor: fix cross ns perm of unix domain sockets * Xenial update to v4.4.59 stable release (LP: #1678960) - xfrm: policy: init locks early - virtio_balloon: init 1st buffer in stats vq - pinctrl: qcom: Don't clear status bit on irq_unmask - c6x/ptrace: Remove useless PTRACE_SETREGSET implementation - h8300/ptrace: Fix incorrect register transfer count - mips/ptrace: Preserve previous registers for short regset write - sparc/ptrace: Preserve previous registers for short regset write - metag/ptrace: Preserve previous registers for short regset write - metag/ptrace: Provide default TXSTATUS for short NT_PRSTATUS - metag/ptrace: Reject partial NT_METAG_RPIPE writes - fscrypt: remove broken support for detecting keyring key revocation - sched/rt: Add a missing rescheduling point - Linux 4.4.59 * Update ENA driver to 1.1.2 from net-next (LP: #1664312) - net: ena: Remove unnecessary pci_set_drvdata() - net: ena: Fix error return code in ena_device_init() - net: ena: change the return type of ena_set_push_mode() to be void. - net: ena: use setup_timer() and mod_timer() - net/ena: remove ntuple filter support from device feature list - net/ena: fix queues number calculation - net/ena: fix ethtool RSS flow configuration - net/ena: fix RSS default hash configuration - net/ena: fix NULL dereference when removing the driver after device reset failed - net/ena: refactor ena_get_stats64 to be atomic context safe - net/ena: fix potential access to freed memory during device reset - net/ena: use READ_ONCE to access completion descriptors - net/ena: reduce the severity of ena printouts - net/ena: change driver's default timeouts - net/ena: change condition for host attribute configuration - net/ena: update driver version to 1.1.2 * Xenial update to v4.4.58 stable release (LP: #1677600) - net/openvswitch: Set the ipv6 source tunnel key
[Kernel-packages] [Bug 1656121] Re: unexpected errno=13 and disconnected path when trying to open /proc/1/ns/mnt from a unshared mount namespace
** Changed in: linux (Ubuntu Xenial)
Status: Triaged => Fix Committed
--
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:
Triaged
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
[Kernel-packages] [Bug 1656121] Re: unexpected errno=13 and disconnected path when trying to open /proc/1/ns/mnt from a unshared mount namespace
** Changed in: linux (Ubuntu Yakkety)
Status: Fix Released => Triaged
--
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:
Triaged
Status in linux source package in Yakkety:
Triaged
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 : htt
[Kernel-packages] [Bug 1656121] Re: unexpected errno=13 and disconnected path when trying to open /proc/1/ns/mnt from a unshared mount namespace
This bug was fixed in the package linux - 4.8.0-45.48
---
linux (4.8.0-45.48) yakkety; urgency=low
* CVE-2017-7184
- xfrm_user: validate XFRM_MSG_NEWAE XFRMA_REPLAY_ESN_VAL replay_window
- xfrm_user: validate XFRM_MSG_NEWAE incoming ESN size harder
-- Stefan Bader Fri, 24 Mar 2017 12:03:39
+0100
** Changed in: linux (Ubuntu Yakkety)
Status: Triaged => Fix Released
** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2017-7184
--
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:
Triaged
Status in linux source package in Yakkety:
Fix Released
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 fro
[Kernel-packages] [Bug 1656121] Re: unexpected errno=13 and disconnected path when trying to open /proc/1/ns/mnt from a unshared mount namespace
Not fixed because we had to revert the commits due to various
regressions.
** Changed in: linux (Ubuntu Xenial)
Status: Fix Released => Triaged
** Changed in: linux (Ubuntu Yakkety)
Status: Fix Released => Triaged
--
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:
Triaged
Status in linux source package in Yakkety:
Triaged
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:
[Kernel-packages] [Bug 1656121] Re: unexpected errno=13 and disconnected path when trying to open /proc/1/ns/mnt from a unshared mount namespace
** Tags removed: verification-needed-xenial verification-needed-yakkety
** Tags added: verification-done-xenial verification-done-yakkety
--
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 Released
Status in linux source package in Yakkety:
Fix Released
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
[Kernel-packages] [Bug 1656121] Re: unexpected errno=13 and disconnected path when trying to open /proc/1/ns/mnt from a unshared mount namespace
This bug was fixed in the package linux - 4.8.0-40.43 --- linux (4.8.0-40.43) yakkety; urgency=low * linux: 4.8.0-40.43 -proposed tracker (LP: #1667066) [ Andy Whitcroft ] * NFS client : permission denied when trying to access subshare, since kernel 4.4.0-31 (LP: #1649292) - fs: Better permission checking for submounts * shaking screen (LP: #1651981) - drm/radeon: drop verde dpm quirks * [0bda:0328] Card reader failed after S3 (LP: #1664809) - usb: hub: Wait for connection to be reestablished after port reset * linux-lts-xenial 4.4.0-63.84~14.04.2 ADT test failure with linux-lts-xenial 4.4.0-63.84~14.04.2 (LP: #1664912) - SAUCE: apparmor: fix link auditing failure due to, uninitialized var * In Ubuntu 17.04 : after reboot getting message in console like Unable to open file: /etc/keys/x509_ima.der (-2) (LP: #1656908) - SAUCE: ima: Downgrade error to warning * 16.04.2: Extra patches for POWER9 (LP: #1664564) - powerpc/mm: Fix no execute fault handling on pre-POWER5 - powerpc/mm: Fix spurrious segfaults on radix with autonuma * ibmvscsis: Add SGL LIMIT (LP: #1662551) - ibmvscsis: Add SGL limit * [Hyper-V] Bug fixes for storvsc (tagged queuing, error conditions) (LP: #1663687) - scsi: storvsc: Enable tracking of queue depth - scsi: storvsc: Remove the restriction on max segment size - scsi: storvsc: Enable multi-queue support - scsi: storvsc: use tagged SRB requests if supported by the device - scsi: storvsc: properly handle SRB_ERROR when sense message is present - scsi: storvsc: properly set residual data length on errors * Ubuntu16.10-KVM:Big configuration with multiple guests running SRIOV VFs caused KVM host hung and all KVM guests down. (LP: #1651248) - KVM: PPC: Book 3S: XICS cleanup: remove XICS_RM_REJECT - KVM: PPC: Book 3S: XICS: correct the real mode ICP rejecting counter - KVM: PPC: Book 3S: XICS: Fix potential issue with duplicate IRQ resends - KVM: PPC: Book 3S: XICS: Implement ICS P/Q states - KVM: PPC: Book 3S: XICS: Don't lock twice when checking for resend * ISST-LTE:pNV: ppc64_cpu command is hung w HDs, SSDs and NVMe (LP: #1662666) - blk-mq: Avoid memory reclaim when remapping queues - blk-mq: Fix failed allocation path when mapping queues - blk-mq: Always schedule hctx->next_cpu * systemd-udevd hung in blk_mq_freeze_queue_wait testing unpartitioned NVMe drive (LP: #1662673) - percpu-refcount: fix reference leak during percpu-atomic transition * [Yakkety SRU] Enable KEXEC support in ARM64 kernel (LP: #1662554) - [Config] Enable KEXEC support in ARM64. * [Hyper-V] Fix ring buffer handling to avoid host throttling (LP: #1661430) - Drivers: hv: vmbus: On write cleanup the logic to interrupt the host - Drivers: hv: vmbus: On the read path cleanup the logic to interrupt the host - Drivers: hv: vmbus: finally fix hv_need_to_signal_on_read() * brd module compiled as built-in (LP: #1593293) - CONFIG_BLK_DEV_RAM=m * regession tests failing after stackprofile test is run (LP: #1661030) - SAUCE: fix regression with domain change in complain mode * Permission denied and inconsistent behavior in complain mode with 'ip netns list' command (LP: #1648903) - SAUCE: fix regression with domain change in complain mode * flock not mediated by 'k' (LP: #1658219) - SAUCE: apparmor: flock mediation is not being enforced on cache check * unexpected errno=13 and disconnected path when trying to open /proc/1/ns/mnt from a unshared mount namespace (LP: #1656121) - SAUCE: apparmor: null profiles should inherit parent control flags * apparmor refcount leak of profile namespace when removing profiles (LP: #1660849) - SAUCE: apparmor: fix ns ref count link when removing profiles from policy * tor in lxd: apparmor="DENIED" operation="change_onexec" namespace="root//CONTAINERNAME_" profile="unconfined" name="system_tor" (LP: #1648143) - SAUCE: apparmor: Fix no_new_privs blocking change_onexec when using stacked namespaces * apparmor_parser hangs indefinitely when called by multiple threads (LP: #1645037) - SAUCE: apparmor: fix lock ordering for mkdir * apparmor leaking securityfs pin count (LP: #1660846) - SAUCE: apparmor: fix leak on securityfs pin count * apparmor reference count leak when securityfs_setup_d_inode\ () fails (LP: #1660845) - SAUCE: apparmor: fix reference count leak when securityfs_setup_d_inode() fails * apparmor not checking error if security_pin_fs() fails (LP: #1660842) - SAUCE: apparmor: fix not handling error case when securityfs_pin_fs() fails * apparmor oops in bind_mnt when dev_path lookup fails (LP: #1660840) - SAUCE: apparmor: fix oops in bind_mnt when dev_path lookup fails * apparmor auditing denied access of special apparmor .null fi\ le (LP: #1660836) - SAUCE: apparmor:
[Kernel-packages] [Bug 1656121] Re: unexpected errno=13 and disconnected path when trying to open /proc/1/ns/mnt from a unshared mount namespace
This bug was fixed in the package linux - 4.4.0-65.86 --- linux (4.4.0-65.86) xenial; urgency=low * linux: 4.4.0-65.86 -proposed tracker (LP: #1667052) [ Stefan Bader ] * Upgrade Redpine RS9113 driver to support AP mode (LP: #1665211) - SAUCE: Redpine driver to support Host AP mode * NFS client : permission denied when trying to access subshare, since kernel 4.4.0-31 (LP: #1649292) - fs: Better permission checking for submounts * [Hyper-V] SAUCE: pci-hyperv fixes for SR-IOV on Azure (LP: #1665097) - SAUCE: PCI: hv: Fix wslot_to_devfn() to fix warnings on device removal - SAUCE: pci-hyperv: properly handle pci bus remove - SAUCE: pci-hyperv: lock pci bus on device eject * [Hyper-V/Azure] Please include Mellanox OFED drivers in Azure kernel and image (LP: #1650058) - net/mlx4_en: Fix bad WQE issue - net/mlx4_core: Fix racy CQ (Completion Queue) free - net/mlx4_core: Fix when to save some qp context flags for dynamic VST to VGT transitions - net/mlx4_core: Avoid command timeouts during VF driver device shutdown * Xenial update to v4.4.49 stable release (LP: #1664960) - ARC: [arcompact] brown paper bag bug in unaligned access delay slot fixup - selinux: fix off-by-one in setprocattr - Revert "x86/ioapic: Restore IO-APIC irq_chip retrigger callback" - cpumask: use nr_cpumask_bits for parsing functions - hns: avoid stack overflow with CONFIG_KASAN - ARM: 8643/3: arm/ptrace: Preserve previous registers for short regset write - target: Don't BUG_ON during NodeACL dynamic -> explicit conversion - target: Use correct SCSI status during EXTENDED_COPY exception - target: Fix early transport_generic_handle_tmr abort scenario - target: Fix COMPARE_AND_WRITE ref leak for non GOOD status - ARM: 8642/1: LPAE: catch pending imprecise abort on unmask - mac80211: Fix adding of mesh vendor IEs - netvsc: Set maximum GSO size in the right place - scsi: zfcp: fix use-after-free by not tracing WKA port open/close on failed send - scsi: aacraid: Fix INTx/MSI-x issue with older controllers - scsi: mpt3sas: disable ASPM for MPI2 controllers - xen-netfront: Delete rx_refill_timer in xennet_disconnect_backend() - ALSA: seq: Fix race at creating a queue - ALSA: seq: Don't handle loop timeout at snd_seq_pool_done() - drm/i915: fix use-after-free in page_flip_completed() - Linux 4.4.49 * NFS client : kernel 4.4.0-57 crash with nfsv4 enries in /etc/fstab (LP: #1650336) - SUNRPC: fix refcounting problems with auth_gss messages. * [0bda:0328] Card reader failed after S3 (LP: #1664809) - usb: hub: Wait for connection to be reestablished after port reset * linux-lts-xenial 4.4.0-63.84~14.04.2 ADT test failure with linux-lts-xenial 4.4.0-63.84~14.04.2 (LP: #1664912) - SAUCE: apparmor: fix link auditing failure due to, uninitialized var * ibmvscsis: Add SGL LIMIT (LP: #1662551) - ibmvscsis: Add SGL limit * [Hyper-V] Bug fixes for storvsc (tagged queuing, error conditions) (LP: #1663687) - scsi: storvsc: Enable tracking of queue depth - scsi: storvsc: Remove the restriction on max segment size - scsi: storvsc: Enable multi-queue support - scsi: storvsc: use tagged SRB requests if supported by the device - scsi: storvsc: properly handle SRB_ERROR when sense message is present - scsi: storvsc: properly set residual data length on errors * ISST-LTE:pNV: ppc64_cpu command is hung w HDs, SSDs and NVMe (LP: #1662666) - blk-mq: Avoid memory reclaim when remapping queues - blk-mq: Fix failed allocation path when mapping queues * Possible missing firmware /lib/firmware/i915/kbl_dmc_ver1.bin for module i915_bpo (LP: #1624164) - SAUCE: i915_bpo: Remove MODULE_FIRMWARE statement for i915/kbl_dmc_ver1.bin * Intel I210 ethernet does not work both after S3 (LP: #1662763) - igb: implement igb_ptp_suspend - igb: call igb_ptp_suspend during suspend/resume cycle * [Hyper-V] Fix ring buffer handling to avoid host throttling (LP: #1661430) - Drivers: hv: vmbus: On write cleanup the logic to interrupt the host - Drivers: hv: vmbus: On the read path cleanup the logic to interrupt the host - Drivers: hv: vmbus: finally fix hv_need_to_signal_on_read() * brd module compiled as built-in (LP: #1593293) - [Config] CONFIG_BLK_DEV_RAM=m * regession tests failing after stackprofile test is run (LP: #1661030) - SAUCE: fix regression with domain change in complain mode * Permission denied and inconsistent behavior in complain mode with 'ip netns list' command (LP: #1648903) - SAUCE: fix regression with domain change in complain mode * flock not mediated by 'k' (LP: #1658219) - SAUCE: apparmor: flock mediation is not being enforced on cache check * unexpected errno=13 and disconnected path when trying to open /proc/1/ns/mnt from a unshared mount namespac
[Kernel-packages] [Bug 1656121] Re: unexpected errno=13 and disconnected path when trying to open /proc/1/ns/mnt from a unshared mount namespace
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
yakkety' to 'verification-done-yakkety'. If the problem still exists,
change the tag 'verification-needed-yakkety' to 'verification-failed-
yakkety'.
If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.
See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!
--
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
[Kernel-packages] [Bug 1656121] Re: unexpected errno=13 and disconnected path when trying to open /proc/1/ns/mnt from a unshared mount namespace
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'. If the problem still exists,
change the tag 'verification-needed-xenial' to 'verification-failed-
xenial'.
If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.
See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!
** Tags added: verification-needed-xenial
** Tags added: verification-needed-yakkety
--
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
A
[Kernel-packages] [Bug 1656121] Re: unexpected errno=13 and disconnected path when trying to open /proc/1/ns/mnt from a unshared mount namespace
** Changed in: linux (Ubuntu Yakkety)
Status: New => Fix Committed
** Changed in: linux (Ubuntu Xenial)
Status: New => Fix Committed
--
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.l
[Kernel-packages] [Bug 1656121] Re: unexpected errno=13 and disconnected path when trying to open /proc/1/ns/mnt from a unshared mount namespace
** Also affects: linux (Ubuntu Yakkety)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Xenial)
Importance: Undecided
Status: New
--
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:
New
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-pac
