[Group.of.nepali.translators] [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
[Group.of.nepali.translators] [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 नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs 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/~group.of.nepali.translators Post to : gro
[Group.of.nepali.translators] [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 नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs 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
[Group.of.nepali.translators] [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 नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs 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/1
[Group.of.nepali.translators] [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:
[Group.of.nepali.translators] [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 नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs 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 __