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 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 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to zfs-linux in Ubuntu. 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 Committed Status in zfs-linux package in Ubuntu: Confirmed Status in linux source package in Xenial: Fix Committed Status in zfs-linux source package in Xenial: Confirmed Status in linux source package in Yakkety: Fix Committed Status in zfs-linux source package in Yakkety: Confirmed 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 -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
