group.of.nepali.translators team mailing list archive

[Brad Figg <brad.figg@xxxxxxxxxxxxx>]

** 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