Add Linux namespace delegation support #12263

allanjude · 2021-06-21T20:41:10Z

Signed-off-by: Will Andrews will.andrews@klarasystems.com
Signed-off-by: Allan Jude allan@klarasystems.com
Sponsored-by: Buddy https://buddy.works

Motivation and Context

This allows ZFS datasets to be delegated to a user/mount namespace
Within that namespace, only the delegated datasets are visible
Works very similarly to Zones/Jailes on other ZFS OSes

Description

Replaces the existing INGLOBALZONE() to actually detect if ZFS is running in the root user namespace or not. When in another user namespace, only delegated ZFS datasets are visible.

How Has This Been Tested?

As a user:

$ unshare -Um
$ zfs list
no datasets available
$ readlink /proc/$$/ns/user
user:[4026532291]

As root:

# zfs list
NAME                            ZONED  MOUNTPOINT
containers                      off    /containers
containers/host                 off    /containers/host
containers/host/child           off    /containers/host/child
containers/host/child/gchild    off    /containers/host/child/gchild
containers/unpriv               on     /unpriv
containers/unpriv/child         on     /unpriv/child
containers/unpriv/child/gchild  on     /unpriv/child/gchild
# zfs userns attach 4026532291 containers/unpriv

Back to the user namespace:

$ zfs list
NAME                             USED  AVAIL     REFER  MOUNTPOINT
containers                       129M  47.8G       24K  /containers
containers/unpriv                128M  47.8G       24K  /unpriv
containers/unpriv/child          128M  47.8G      128M  /unpriv/child

This has also been tested on Ubuntu 20.04 with LXD containers.

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Performance enhancement (non-breaking change which improves efficiency)
Code cleanup (non-breaking change which makes code smaller or more readable)
Breaking change (fix or feature that would cause existing functionality to change)
Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
Documentation (a change to man pages or other documentation)

Checklist:

My code follows the OpenZFS code style requirements.
I have updated the documentation accordingly.
I have read the contributing document.
I have added tests to cover my changes.
I have run the ZFS Test Suite with this change applied.
All commit messages are properly formatted and contain Signed-off-by.

sempervictus · 2021-06-24T15:36:51Z

Thank you!
Is the hardcoded root namespace value the same across all supported distributions and kernels?

mskarbek · 2021-06-28T08:09:53Z

I have briefly played with this on RHEL 8.4 (kernel-4.18.0-305.3.1.el8_4.x86_64) and I have few questions:

If I delegate a datatset why am I able to see in namespace all parent datasets all the way up to the root? Is that intended?
Is this function will be able to cooperate with 'allow' at some point on non-root accounts? Currently, a normal user is unable to delegate datatset. I'm thinking about making this usable in the context of rootless containers.

EDIT: https://www.redhat.com/sysadmin/podman-rootless-overlay

allanjude · 2021-06-28T13:55:01Z

I have briefly played with this on RHEL 8.4 (kernel-4.18.0-305.3.1.el8_4.x86_64) and I have few questions:
* If I delegate a datatset why am I able to see in namespace all parent datasets all the way up to the root? Is that intended?

Yes, this is how it works in Zones and Jails as well, you can see the path between the delegated dataset and the root. You do not have access to modify them. There was talk in a previous leadership meeting about a way to alias the path back to the root, to a) make it shorter to save having really long dataset names, and b) hide some of the layout from the user in the delegated container. This might be an interesting additional project.

* Is this function will be able to cooperate with 'allow' at some point on non-root accounts? Currently, a normal user is unable to delegate datatset. I'm thinking about making this usable in the context of rootless containers.

EDIT: https://www.redhat.com/sysadmin/podman-rootless-overlay

Do you mean, could you zfs allow the userns add command? I suppose so. Currently, our tests use rootless containers, but do the delegation as root. I can see the usefulness of allowing it.

allanjude · 2021-06-28T13:55:35Z

Thank you!
Is the hardcoded root namespace value the same across all supported distributions and kernels?

As far as we know. Is there a constant/#define provided by the Kernel we should be using instead?

ghost · 2021-07-06T20:43:04Z

Changing GLOBAL_ZONEID in libspl is what broke things on FreeBSD. It causes checks in share_mount_one() in cmd/zfs/zfs_main.c to fail, resulting in the error message "cannot %s '%s': permission denied" throughout the test log.

allanjude · 2021-07-21T18:43:49Z

The failure seems odd:

Test: /usr/share/zfs/zfs-tests/tests/functional/removal/removal_remap_deadlists (run as root) [00:08] [FAIL]
23:49:55.13 NOTE: begin default_setup_noexit
23:49:55.34 SUCCESS: zpool create -f testpool loop0 loop1 loop2
23:49:55.41 SUCCESS: zfs create testpool/testfs
23:49:55.43 SUCCESS: zfs set mountpoint=/mnt/testdir testpool/testfs
23:49:55.66 SUCCESS: dd if=/dev/zero of=/mnt/testdir/file bs=1024k count=300
23:49:58.90 SUCCESS: zfs snapshot testpool/testfs@snap-pre1
23:49:58.95 SUCCESS: dd if=/dev/zero of=/mnt/testdir/file bs=1024k count=100 conv=notrunc seek=100
23:50:00.42 SUCCESS: zfs snapshot testpool/testfs@snap-pre2
23:50:00.47 SUCCESS: dd if=/dev/zero of=/mnt/testdir/file bs=1024k count=100 conv=notrunc seek=200
23:50:02.73 SUCCESS: zpool remove testpool loop0
23:50:02.75 SUCCESS: is_pool_removing testpool
23:50:02.84 ERROR: zdb -cd testpool exited 267
23:50:02.84 /usr/share/zfs/zfs-tests/tests/functional/removal/removal_remap_deadlists.ksh[38]: log_must[67]: log_pos[270]: attempt_during_removal[75]: log_must[67]: log_pos: line 270: 2127913: Memory fault

cmd/zfs/zfs_main.c

lib/libspl/os/linux/zone.c

module/os/linux/spl/spl-zone.c

module/os/linux/zfs/zfs_ioctl_os.c

allanjude · 2021-09-14T19:02:21Z

I just fixed the example in the commit message, which was wrong after we changed the subcommand from zfs userns add to zfs userns attach

cmd/zfs/zfs_main.c

lib/libnvpair/libnvpair.abi

man/man8/zfs-userns.8

include/os/linux/kernel/linux/vfs_compat.h

lib/libspl/os/linux/zone.c

module/os/linux/spl/spl-zone.c

module/os/linux/zfs/zfs_ioctl_os.c

module/os/linux/spl/spl-zone.c

module/os/linux/zfs/zfs_vfsops.c

This allows ZFS datasets to be delegated to a user/mount namespace Within that namespace, only the delegated datasets are visible Works very similarly to Zones/Jailes on other ZFS OSes As a user: ``` $ unshare -Um $ zfs list no datasets available $ echo $$ 1234 ``` As root: ``` # zfs list NAME ZONED MOUNTPOINT containers off /containers containers/host off /containers/host containers/host/child off /containers/host/child containers/host/child/gchild off /containers/host/child/gchild containers/unpriv on /unpriv containers/unpriv/child on /unpriv/child containers/unpriv/child/gchild on /unpriv/child/gchild # zfs zone /proc/1234/ns/user containers/unpriv ``` Back to the user namespace: ``` $ zfs list NAME USED AVAIL REFER MOUNTPOINT containers 129M 47.8G 24K /containers containers/unpriv 128M 47.8G 24K /unpriv containers/unpriv/child 128M 47.8G 128M /unpriv/child ``` Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Will Andrews <will.andrews@klarasystems.com> Signed-off-by: Allan Jude <allan@klarasystems.com> Signed-off-by: Mateusz Piotrowski <mateusz.piotrowski@klarasystems.com> Co-authored-by: Allan Jude <allan@klarasystems.com> Co-authored-by: Mateusz Piotrowski <mateusz.piotrowski@klarasystems.com> Sponsored-by: Buddy <https://buddy.works> Closes openzfs#12263

When read and writing the UID/GID, we always want the value relative to the root user namespace, the kernel will take care of remapping this to the user namespace for us. Calling from_kuid(user_ns, uid) with a unmapped uid will return -1 as that uid is outside of the scope of that namespace, and will result in the files inside the namespace all being owned by 'nobody' and not being allowed to call chmod or chown on them. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Allan Jude <allan@klarasystems.com> Closes openzfs#12263