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_<var-lib-lxd>" 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: 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
* Enable CONFIG_NET_DROP_MONITOR=m in Ubuntu Kernel (LP: #1660634)
- [Config] CONFIG_NET_DROP_MONITOR=m
* Linux kernel 4.8 hangs at boot up (LP: #1659340)
- SAUCE: x86/efi: Always map first physical page into EFI pagetables
* s390/kconfig: CONFIG_NUMA without CONFIG_NUMA_EMU does not make any sense on
s390x (LP: #1557690)
- [Config] CONFIG_NUMA_BALANCING=y
- [Config] CONFIG_NUMA=y, CONFIG_NUMA_EMU=y for s390x
-- Thadeu Lima de Souza Cascardo <casca...@canonical.com> Wed, 22 Feb
2017 15:03:35 -0300
** Changed in: linux (Ubuntu Yakkety)
Status: Fix Committed => Fix Released
** Changed in: linux (Ubuntu Xenial)
Status: Fix Committed => Fix Released
--
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:
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/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help : https://help.launchpad.net/ListHelp
