ZFS rootless can't set pool name

[awhileback]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

zfs allow a user to perform zfs dataset commands and try to start a rootless container

it seems I am missing a means of setting the root pool for the zfs command, or podman is not picking up the setting properly (I have tried fs="rpool" and fsname="rpool" under storage.conf to no avail)

[storage]
# Default Storage Driver, Must be set for proper operation.
driver = "zfs"

# Temporary storage location
runroot = "/opt/podman/.local/share/containers/run"

# Primary Read/Write location of container storage
graphroot = "/opt/podman/.local/share/containers/storage"

[storage.options.zfs]
fsname="rpool"
mountopt="nodev"

zfs allow rpool/podman
---- Permissions on rpool/podman -------------------------------------
Local+Descendent permissions:
	user podman create,destroy,mount,snapshot

Steps to reproduce the issue:

1. install podman from kubic repo for ubuntu 20.04

2. grant a user zfs dataset permissions

3. try to create a rootless container after specifying storage.conf in the user's local .config

Describe the results you received:

podman build --volume /opt/podman/pgsql_data:/var/lib/pgsql/data:U postgres -t postgres
STEP 1: FROM centos:latest
Resolved "centos" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull quay.io/centos/centos:latest...
Getting image source signatures
Copying blob 7a0437f04f83 done  
Copying config 300e315adb done  
Writing manifest to image destination
Storing signatures
Error: error creating build container: Error committing the finished image: error adding layer with blob
 "sha256:7a0437f04f83f084b7ed68ad9c4a4947e12fc4e1b006b38129bac89114ec3621": error creating layer with ID
 "2653d992f4ef2bfd27f94db643815aa567240c37732cae1405ad1c1309ee9859": exit status 1: "/sbin/zfs fs create -o
 mountpoint=legacy rpool/podman/2653d992f4ef2bfd27f94db643815aa567240c37732cae1405ad1c1309ee9859" =>
 cannot create 'rpool/podman/2653d992f4ef2bfd27f94db643815aa567240c37732cae1405ad1c1309ee9859': permission
 denied

As you can see podman is trying to use the pool "fs." I don't have a pool named "fs."

Describe the results you expected:

build a rootless podman image

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

Version:      3.2.3
API Version:  3.2.3
Go Version:   go1.15.2
Built:        Thu Jan  1 00:00:00 1970
OS/Arch:      linux/amd64

host:
  arch: amd64
  buildahVersion: 1.21.3
  cgroupControllers: []
  cgroupManager: cgroupfs
  cgroupVersion: v1
  conmon:
    package: 'conmon: /usr/libexec/podman/conmon'
    path: /usr/libexec/podman/conmon
    version: 'conmon version 2.0.27, commit: '
  cpus: 4
  distribution:
    distribution: ubuntu
    version: "20.04"
  eventLogger: journald
  hostname: NAS
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 27
      size: 1
    - container_id: 1
      host_id: 624288
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1008
      size: 1
    - container_id: 1
      host_id: 624288
      size: 65536
  kernel: 5.4.0-81-generic
  linkmode: dynamic
  memFree: 20561178624
  memTotal: 33558417408
  ociRuntime:
    name: crun
    package: 'crun: /usr/bin/crun'
    path: /usr/bin/crun
    version: |-
      crun version 0.20.1.5-925d-dirty
      commit: 0d42f1109fd73548f44b01b3e84d04a279e99d2e
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    path: /run/user/1008/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: 'slirp4netns: /usr/bin/slirp4netns'
    version: |-
      slirp4netns version 1.1.8
      commit: unknown
      libslirp: 4.3.1-git
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.4.3
  swapFree: 4294963200
  swapTotal: 4294963200
  uptime: 1h 41m 52.49s (Approximately 0.04 days)
registries:
  search:
  - docker.io
  - quay.io
store:
  configFile: /opt/podman/.config/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: zfs
  graphOptions:
    zfs.fsname: rpool
    zfs.mountopt: nodev
  graphRoot: /opt/podman/.local/share/containers/storage
  graphStatus:
    Compression: lz4
    Parent Dataset: rpool
    Parent Quota: "no"
    Space Available: "201948008448"
    Space Used By Parent: "37294673920"
    Zpool: rpool
    Zpool Health: ONLINE
  imageStore:
    number: 0
  runRoot: /opt/podman/.local/share/containers/run
  volumePath: /opt/podman/.local/share/containers/storage/volumes
version:
  APIVersion: 3.2.3
  Built: 0
  BuiltTime: Thu Jan  1 00:00:00 1970
  GitCommit: ""
  GoVersion: go1.15.2
  OsArch: linux/amd64
  Version: 3.2.3

Package info (e.g. output of rpm -q podman or apt list podman):

Listing... Done
podman/unknown,now 100:3.2.3-1 amd64 [installed]
podman/unknown 100:3.2.3-1 arm64
podman/unknown 100:3.2.3-1 armhf
podman/unknown 100:3.2.3-1 s390x

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/master/troubleshooting.md)

Yes, troubleshooting guide doesn't have anything particular to zfs.

I checked the notes related to storage and filesystem config between my version and the current, is this possibly also #10264? not sure...

Additional environment details (AWS, VirtualBox, physical, etc.):

[awhileback]

tried on /testing (3.3.0) and got the same result.

the command being generated is wrong.

/sbin/zfs fs create -o mountpoint=legacy rpool/podman/2653d992f4ef2bfd27f94db643...

...can't work. The command should be...

/sbin/zfs create -o mountpoint=legacy rpool/podman/2653d992f4ef2bfd27f94db643815aa567240c3773...

[mheon]

@nalind This seems like it should be moved to c/storage

[awhileback]

Actually, upon further investigation this is not a bug, it seems. Despite the fact that the user can be granted "create" ability on linux ZFS, the user can't use it without permission to the mount command which Linux unprivileged users don't have.

Would be nice to put a blurb in the docs for ZFS, I suppose that explains this.

podman@NAS ~ $ zfs allow
Usage: 	allow <filesystem|volume>
	allow [-ldug] <"everyone"|user|group>[,...] <perm|@setname>[,...]
	    <filesystem|volume>
	allow [-ld] -e <perm|@setname>[,...] <filesystem|volume>
	allow -c <perm|@setname>[,...] <filesystem|volume>
	allow -s @setname <perm|@setname>[,...] <filesystem|volume>

Options:
  -h          show this help message and exit
  -l          set permission locally
  -d          set permission for descents
  -u          set permission for user
  -g          set permission for group
  -e          set permission for everyone
  -c          set create time permission
  -s          define permission set

The following permissions are supported:

NAME             TYPE          	NOTES
allow            subcommand    	Must also have the permission that is being
				allowed
clone            subcommand    	Must also have the 'create' ability and 'mount'
				ability in the origin file system
create           subcommand    	Must also have the 'mount' ability <------------------

I checked building a root container with the same storage.conf and it worked fine, so this has to be the user's inability to mount in Linux causing the failure.

[rhatdan]

Please open a PR with the docs changes, if you want it.