How to mount dir accessed via supplemental group as overlay volume mount? (Rootless Podman)

[nate-howard]

I have a directory on the host machine that I access via a supplemental group, and I would like to mount this directory into a container with an overlay volume mount.

This is essentially the setup (host):

% ls -al dir_to_mount
drwxr-x---  root supp_group  .
drwxr-xr-x  root root        ..
drwxrwxr-x  root supp_group  d1
drwxrwxr-x  root supp_group  d2
-rw-r--r--  root supp_group  f1
% groups
group1 supp_group

I can mount this successfully with a regular bind mount:
podman run --rm -it --runtime crun --group-add keep-groups -v /path/to/dir_to_mount:/host registry.access.redhat.com/ubi8 bash
This fully works, I can cd into /host/d1 or d2, ls, touch files in d1 or d2, etc.

However, I need the changes in the container to not affect the host machine, so I try to mount as an overlay volume mount:
podman run --rm -it --runtime crun --group-add keep-groups -v /path/to/dir_to_mount:/host:O registry.access.redhat.com/ubi8 bash
And I get this behavior (container):

# cd /host
# ls -al /host
drwxr-x---  nobody nobody  .
dr-xr-xr-x  root   root    ..
drwxrwxr-x  nobody nobody  d1
drwxrwxr-x  nobody nobody  d2
-rw-r--r--  nobody nobody  f1
# cd d1
bash: cd: d1: Operation not supported

It seemed strange to me that I am able to cd into /host, but not /host/d1. I have also tried disabling SELinux labeling(--security-opt label=disable) with the command above, but I got the same results.

The host is a RHEL8 machine at my work, and I don't have admin rights, so rootless podman. Host:

% podman version
Client:       Podman Engine
Version:      4.4.1
API Version:  4.4.1
Go Version:   go1.19.6
Built:        Wed Apr 26 10:13:11 2023
OS/Arch:      linux/amd64

I am fairly new to working with containers, so I don't know if I am missing some configuration or run option, or this can't be done. Alternatively, if there is a better way to access this dir and not have changes in the container affect the host machine, I would love to know about it. Any help is apprecated!

[rhatdan]

Weird, I think you need to look under the covers to see the ownership of the overlay group.
This is likely to be an actual bug,

[rhatdan]

@giuseppe @flouthoc WDYT?

[giuseppe]

the overlay mount is owned by the user namespace and the additional group is not mapped there.

I think overlay itself is blocking access in this case since the file is not owned by a user in the user namespace.

[rhatdan]

Any thoughts on fixing this?

[giuseppe]

that is a security measure in the kernel to prevent accessing files not owned by IDs not in the user namespace. We have no control whether it can be relaxed or not, it happens entirely in the kernel. One possibility could be to use fuse-overlayfs, as this check is not in place (it doesn't need that since it is anyway running as an unprivileged process)

[nate-howard]

Using fuse-overlayfs worked! Additionally, the crun and keep-groups options are no longer needed.