the issue here is that you are mapping your own user to the same id
inside of the user namespace.
That means the root user inside of the user namespace will be mapped to
another ID, which is the first ID specified in /etc/sub?id for your
user.  It is the same user that will configure the mount namespace,
including the bind mount that fails in your test.
The OCI runtime, after changing uid/gid to the specified ones (with
--userns=keep-id are the same $UID:$GID you have on the host), drops any
additional group that the user had when launching the container.
I've added a function to crun 0.10.4 to have the possibility to not drop
additional groups for such cases, it can be enabled from podman with
"--annotation io.crun.keep_original_groups=1", it might help you.
Giuseppe
mh <mh+podman(a)scrit.ch> writes:
 Hi All,
 trying to do the following, but it won't work neither on fedora nor EL7
 $ cat /etc/fedora-release
 Fedora release 30 (Thirty)
 $ podman version
 Version:            1.6.2
 RemoteAPI Version:  1
 Go Version:         go1.12.10
 OS/Arch:            linux/amd64
 $ id -u
 1000
 $ id -g
 1000
 $ mkdir /tmp/foo/bar -p
 $ chmod 0750 /tmp/foo /tmp/foo/bar
 $ echo hello > /tmp/foo/bar/msg
 $ podman run -it --userns=keep-id -v \
   /tmp/foo/bar:/data:rw,Z fedora:31 cat /data/msg
 hello
 -> this works
 $ sudo chown root /tmp/foo
 $ ls -anl /tmp/foo
 total 0
 drwxr-x---.  3    0 1000   60  5. Nov 23:29 .
 drwxrwxrwt. 30    0    0 2420  5. Nov 23:34 ..
 drwxr-x---.  2 1000 1000   60  5. Nov 23:30 bar
 $ podman run -it --userns=keep-id -v \
   /tmp/foo/bar:/data:rw,Z fedora:31 cat /data/msg
 Error: time="2019-11-05T23:35:13+01:00" level=warning msg="exit status
1"
 time="2019-11-05T23:35:13+01:00" level=error
 msg="container_linux.go:346: starting container process caused
 \"process_linux.go:449: container init caused \\\"rootfs_linux.go:58:
 mounting \\\\\\\"/tmp/foo/bar\\\\\\\" to rootfs
\\\\\\\"/home/mh/.local/share/containers/storage/overlay/d7b7bfe26e90a616a818c9210ad63da0d74c0c13c0b78c671034c7a6bb9e5cde/merged\\\\\\\"
 at \\\\\\\"/data\\\\\\\" caused \\\\\\\"stat /tmp/foo/bar: permission
 denied\\\\\\\"\\\"\""
 container_linux.go:346: starting container process caused
 "process_linux.go:449: container init caused \"rootfs_linux.go:58:
 mounting \\\"/tmp/foo/bar\\\" to rootfs
\\\"/home/mh/.local/share/containers/storage/overlay/d7b7bfe26e90a616a818c9210ad63da0d74c0c13c0b78c671034c7a6bb9e5cde/merged\\\"
 at \\\"/data\\\" caused \\\"stat /tmp/foo/bar: permission
denied\\\"\"":
 OCI runtime permission denied error
 -> this fails somehow, although my user has rights in that path.
 $ sudo chmod 0755 /tmp/foo
 $ ls -anl /tmp/foo
 total 0
 drwxr-xr-x.  3    0 1000   60  5. Nov 23:29 .
 drwxrwxrwt. 30    0    0 2420  5. Nov 23:35 ..
 drwxr-x---.  2 1000 1000   60  5. Nov 23:30 bar
 $ podman run -it --userns=keep-id -v \
   /tmp/foo/bar:/data:rw,Z fedora:31 cat /data/msg
 hello
 So whenever a directory in the path to the volume that should go into my
 container is not browseable by my uid (although my group can!) I cannot
 mount it as a volume.
 debug logs won't give any further info.
 Why do I want to do that?
 I have userdirectories that are purely used as chroots for SFTP through
 sshd. Thus they *must* be root owned, but group readable/listable, so
 the root of the chroot can't be overwritten. See sshd_config for more
 details.
 Now I'd like to run containers as the particular user, operating on some
 directories within that chroot path.
 By default these chroot-directories are setup with 0750 and thus failing
 in my case.
 While 0755 might still be an option/workaround, I am wondering what the
 reason for that requirement is?
 It looks like a bug to me. Shall I open an issue, but where?
 ~mh
 _______________________________________________
 Podman mailing list -- podman(a)lists.podman.io
 To unsubscribe send an email to podman-leave(a)lists.podman.io