kernel-packages team mailing list archive
-
kernel-packages team
-
Mailing list archive
-
Message #180601
[Bug 1567558] Re: ZFS is confused by user namespaces (uid/gid mapping) when used with acltype=posixac
I tested this the xenial-proposed kernel (4.4.0-23) on a machine that
was showing the exact symptoms described by the original reporter in
Xenial. Here's the sequence of commands on the -proposed kernel:
root@bonnetmaker:~# uname -a
Linux bonnetmaker 4.4.0-23-lowlatency #41-Ubuntu SMP PREEMPT Mon May 16 23:55:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
root@bonnetmaker:~# zfs create lxd/test -o mountpoint=/tmp/test
root@bonnetmaker:~# zfs set acltype=posixacl lxd/test
root@bonnetmaker:~# cd /tmp/test/
root@bonnetmaker:/tmp/test# mkdir a
root@bonnetmaker:/tmp/test# setfacl -m default:user:100100:rwX a
root@bonnetmaker:/tmp/test# setfacl -m user:100100:rwX a
root@bonnetmaker:/tmp/test# getfacl -n a
# file: a
# owner: 0
# group: 0
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@bonnetmaker:/tmp/test# lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- /bin/bash
bash: /root/.bashrc: Permission denied
root@bonnetmaker:/tmp/test# ls -lh
total 512
drwxrwxr-x+ 2 nobody nogroup 2 May 23 16:24 a
root@bonnetmaker:/tmp/test# 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
root@bonnetmaker:/tmp/test#
Numbers check out - looks like it's working now!
** Tags removed: verification-needed-xenial
** Tags added: verification-done-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 Released
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 Released
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