group.of.nepali.translators team mailing list archive

[Launchpad Bug Tracker <1567558@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package linux - 4.4.0-24.43

---------------
linux (4.4.0-24.43) xenial; urgency=low

  [ Kamal Mostafa ]

  * CVE-2016-1583 (LP: #1588871)
    - ecryptfs: fix handling of directory opening
    - SAUCE: proc: prevent stacking filesystems on top
    - SAUCE: ecryptfs: forbid opening files without mmap handler
    - SAUCE: sched: panic on corrupted stack end

  * arm64: statically link rtc-efi (LP: #1583738)
    - [Config] Link rtc-efi statically on arm64

 -- Kamal Mostafa <kamal@xxxxxxxxxxxxx>  Fri, 03 Jun 2016 10:02:16 -0700

** Changed in: linux (Ubuntu Xenial)
       Status: Fix Committed => Fix Released

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2016-1583

-- 
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/1567558

Title:
  ZFS is confused by user namespaces (uid/gid mapping) when used with
  acltype=posixac

Status in linux package in Ubuntu:
  Fix Released
Status in zfs-linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Released
Status in zfs-linux source package in Xenial:
  Confirmed
Status in linux source package in Yakkety:
  Fix Released
Status in zfs-linux source package in Yakkety:
  Fix Released

Bug description:
  This report is copy/paste from the following upstream issue:
  https://github.com/zfsonlinux/zfs/issues/4177

  I was asked to file a matching Ubuntu bug for tracking.

  
  Hello,

  # First a quick introduction to the world of containers

  I'm the project leader for LXC and LXD, working on containers on
  Linux. We now extensively use the user namespaces to provide an extra
  layer of security in Linux containers.

  The user namespace allows one to map a range of uid and gid from the
  host or parent namespace into another range of uid and gid of a new
  namespace.

  Typically what's done is that 65536 uids and gids are set aside per
  non-system users on the host. Those users through a couple of setuid
  helpers (newuidmap and newgidmap) can then setup a uid and gid map for
  their processes. Their 65536 allocation is therefore mapped from
  uid/gid 0 to 65536 of the new namespace, providing a POSIX-compatible
  environment.

  That means that given a user on the host with uid and gid range 100000
  through 165536, uid 100 in their container will be mapped to uid
  100100 outside of it.

  # The problem with ZFS

  When using ZFS with acltype=posixacl and an ACL entry on the host set
  for a uid (or gid) that's then mapped into the container, the
  container doesn't see the right mapped value when querying the acl
  from inside the namespace.

  # Example with zfs (broken)

  root@dakara:~# zfs create lxd/test -o mountpoint=/tmp/test
  root@dakara:~# zfs set acltype=posixacl lxd/test
  root@dakara:~# cd /tmp/test/
  root@dakara:/tmp/test# mkdir a
  root@dakara:/tmp/test# setfacl -m default:user:100100:rwX a
  root@dakara:/tmp/test# setfacl -m user:100100:rwX a
  root@dakara:/tmp/test# getfacl a
  # file: a
  # owner: root
  # group: root
  user::rwx
  user:100100:rwx
  group::r-x
  mask::rwx
  other::r-x
  default:user::rwx
  default:user:100100:rwx
  default:group::r-x
  default:mask::rwx
  default:other::r-x

  root@dakara:/tmp/test# lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- /bin/bash
  root@dakara:/tmp/test (in userns)# ls -lh
  total 512
  drwxrwxr-x+ 2 nobody nogroup 2 Jan  7 22:19 a

  root@dakara:/tmp/test (in userns)# getfacl -n a
  # file: a
  # owner: nobody
  # group: nogroup
  user::rwx
  user:4294967295:rwx
  group::r-x
  mask::rwx
  other::r-x
  default:user::rwx
  default:user:4294967295:rwx
  default:group::r-x
  default:mask::rwx
  default:other::r-x

  # Example with ext4 (working)

  root@dakara:/tmp/test.ext4# mkdir a

  root@dakara:/tmp/test.ext4# setfacl -m default:user:100100:rwX a

  root@dakara:/tmp/test.ext4# setfacl -m user:100100:rwX a

  root@dakara:/tmp/test.ext4# getfacl a
  # file: a
  # owner: root
  # group: root
  user::rwx
  user:100100:rwx
  group::r-x
  mask::rwx
  other::r-x
  default:user::rwx
  default:user:100100:rwx
  default:group::r-x
  default:mask::rwx
  default:other::r-x

  root@dakara:/tmp/test.ext4# lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- /bin/bash
  root@dakara:/tmp/test.ext4 (in userns)# ls -lh
  total 4.0K
  drwxrwxr-x+ 2 nobody nogroup 4.0K Jan  7 22:22 a

  root@dakara:/tmp/test.ext4 (in userns)# getfacl -n a
  # file: a
  # owner: 65534
  # group: 65534
  user::rwx
  user:100:rwx
  group::r-x
  mask::rwx
  other::r-x
  default:user::rwx
  default:user:100:rwx
  default:group::r-x
  default:mask::rwx
  default:other::r-x

  # Environment

  This was noticed on Ubuntu 14.04 using the zfs stable PPA. I first
  found it in production environments first with file servers
  misbehaving due to the problem, then reproduced it on my development
  systems.

  The zfs version here is 0.6.5.3-1~trusty and I've seen this on 3.13,
  3.16, 3.19 and 4.2 kernels (not that it should matter, the dkms code
  was the same). zfs-dkms is at 2.53-zfs1.

  The lxc-usernsexec helper tool I'm using there comes from the LXC
  package in Ubuntu. It essentially causes a call to fork() followed by
  a call to unshare(CLONE_NEWUSER), then calls the newuidmap and
  newgidmap setuid helpers with the provided map so that the namespace
  can be configured properly.

  You could reproduce something similar using the simple unshare tool
  and manual writes to /proc/PID/{u,g}id_map

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1567558/+subscriptions