Rootless Podman Container Cannot Access Hosts File with Group Read Permission

Resolving group read permission issues for host files in rootless Podman requires ensuring the container user’s primary group matches the file’s owning group and that the mount options explicitly preserve these permissions. This guide explains how to configure podman run with correct --group-add flags and volume mounts to allow non-root OpenLDAP services to access shared certificates securely without escalating privileges.

Understanding Rootless Permission Mapping

In a standard Docker environment, rootless mode often relies on user namespace remapping where the internal root user is mapped to an unprivileged host user. However, Podman handles this differently by default. When you run a container as your regular user, the process inside sees itself as root, but the kernel restricts access to host resources based on the actual UID/GID mapping of the host user running the daemon. The core issue arises when a file on the host, such as a TLS certificate or key, is owned by a specific group (e.g., ssl-cert) with group-read permissions (640). If the container process does not belong to that same GID, or if the mount point strips the group attributes, the application inside will receive a "Permission denied" error. Unlike some other container engines, Podman does not automatically inject all supplementary groups from the host into the container unless explicitly configured. You must manually ensure the group context is passed through. Run Programs with Elevated Privileges: A Comprehensive Guide provides broader context on privilege management, but for this specific scenario, we focus on fine-grained group injection rather than full sudo emulation.

Identifying the Required Group ID

Before modifying your container command, you must identify the exact Group ID (GID) associated with the file you wish to access. Use the ls -l command on the host to inspect the target file. For example:

$ ls -l /etc/pki/tls/private/server.key
-rw-r----- 1 root ldap 1234 Jan 1 12:00 /etc/pki/tls/private/server.key

In this example, the group owner is ldap. Note the GID; you can find it using getent group ldap. Let us assume the GID is 500. Your goal is to make the process inside the Podman container recognize GID 500 as a valid group with read access. It is critical to verify that your current host user is a member of this group. Run id to list your active groups. If your user is not in the ldap group, adding them via usermod -aG ldap $USER is the first step. Without this, even passing the GID to the container may fail because the source file permissions themselves block your host user from reading the data to begin with.

Configuring the Podman Run Command

To grant the container access, you need to use two specific flags during the podman run execution: --group-add and proper volume mounting syntax. The --group-add flag forces the container runtime to add the specified GID to the process’s supplementary groups list. Here is the corrected command structure:

$ podman run \
  --group-add keep-groups \
  -v /etc/pki/tls/private:/etc/pki/tls/private:ro \
  --name openldap-server \
  docker.io/library/openldap:latest

The --group-add keep-groups option is particularly useful in rootless mode. It tells Podman to retain the groups that the host user belongs to and map them into the container. If you know the specific GID, you can also use --group-add 500 directly. The :ro suffix on the volume mount ensures the container cannot write to the host file, which is a security best practice for certificate directories. If you are using a podman-compose.yml file instead of a CLI command, the configuration looks slightly different. Under the service definition, you should include:

services:
  openldap:
    image: docker.io/library/openldap:latest
    volumes:
      - /etc/pki/tls/private:/etc/pki/tls/private:ro
    group_add:
      - keep-groups

This YAML snippet achieves the same result by injecting the host groups into the container environment at startup.

Verifying Access Inside the Container

Once the container is running, log in to verify the permissions are correctly applied. Use podman exec to enter the shell of the running container:

$ podman exec -it openldap-server sh

Inside the container, run id again. You should see the GID corresponding to the host group (e.g., 500) listed in the output. Then, attempt to read the file:

# cat /etc/pki/tls/private/server.key

If the command outputs the key content without errors, the permission issue is resolved. If it still fails, double-check that the host file permissions allow group read access. Sometimes, SELinux policies on the host can interfere with rootless containers accessing specific directories like /etc or /var/lib. In such cases, you may need to adjust SELinux contexts using chcon -Rt svirt_sandbox_file_t /path/to/dir or use the :z or :Z mount options, though :ro is usually sufficient for simple read-only access. Make cURL establish TLS connection with CA unknown discusses related TLS verification issues, but note that permission errors occur before any network handshake begins. Ensuring the file is readable is the prerequisite for successful TLS configuration.

Frequently Asked Questions

Why does my container still say "Permission denied" after adding the group?

Check the host file permissions first. If the file is 600 (owner read/write only), no amount of group injection will help because the group bit is not set. Change the host file permissions to 640 using chmod 640 to enable group read access.

Can I use the same method for Docker rootless containers?

Docker’s rootless implementation differs significantly from Podman. Docker often uses a fixed remapped user (usually 9999:9999) regardless of the host user. While --group-add works in Docker, you must ensure the Docker socket and storage paths are accessible to your unprivileged user, which often requires additional setup compared to Podman’s native approach.

What if I need write access to the mounted directory?

Avoid removing the :ro flag for sensitive files like keys. If you must write, consider mounting a temporary directory inside the container and copying files into it, or use :rw with extreme caution. Write access to host certificate directories from a container is generally discouraged due to security risks.

How do I debug which groups are present in the container?

Use podman exec <container_id> id to print the user and group IDs. Compare this output with id on your host machine. If the target GID is missing, your --group-add flag was either ignored or the host user is not a member of that group.

Does SELinux block rootless containers from reading /etc files?

Yes, SELinux can restrict access. If you see AVC denials in dmesg, you may need to relabel the directory. Use chcon -Rt svirt_sandbox_file_t /your/cert/path to allow the container sandbox to read the files. This is a common hurdle on RHEL-based systems.