3

I'm trying to access a shared certificate key from a rootless Podman container that is running OpenLDAP service as a non-root user. The key has group read rights and the user that is running my container is a member of this group. I wouldn't want to make a copy of the TLS key because then, if the key changes, the key would have to be copied again and this introduces extra complication and risk in the process.

Details:

I'm running the rootless Podman container with user ID 4610 and the user is a member of certs group (ID 1012) and group 4610. The user running the service inside container is not root either (the user ID inside the container is 4610 as well). I'm trying to mount the certificate key on the host which has a ownership root:certs and permissions rw-r----- to the container so that user 4610 inside the container would have access to it. Obviously on the host the user can access the file, because he is a member of certs group and the file has group read permission.

My /etc/subuid and /etc/subgid both have this line:

4610:100000:65536

If my docker-compose file has these lines, the container is allowed to access files whose owner is 4610 on the host:

userns_mode: "keep-id"
user: "4610"

This maps the host UID 4610 to the container so that if I have files whose owner is 4610 on the host, the owner inside the container is seen as 4610 as well. But the key file whose owner is root:certs on the host is seen owned by nobody:nogroup (IDs 65534:65534) inside the container.

How do I achieve the mount so that the user 4610 inside the container has access to the key file?

Marko
  • 49

1 Answers1

1

I was able to solve this after all with the help of Erik Sjölund's tips.

The first solution is to use just podman run, and add --group_add keep-groups option.

If you're using a compose file the solution is to add this to compose file:

services:
...
  service:
    group_add:
      - keep-groups

Keep-groups "keeps" the groups of the user that starts the container i.e. magically allows the container read the file that has the group read permission.

The second option, if you're using podman-compose, is to add a file ~/.config/containers/containers.conf:

[containers]
userns = "keep-id"
annotations=["run.oci.keep_original_groups=1"]

This affects all the user's containers, of course. The ~ folder is naturally the home of the user running the container.

The funny thing was that when I entered the container, the owner or permissions of the file had not changed. The file still seemed to be owned by nobody:nogroup and had permissions: rw-r-----. The user had not been added to this "nogroup" group. But cat {path to key file} still printed the file and the service was able to read it also. I guess it would take some additional acrobatics to also map the group inside the container and make the service user a member of that group.

The last solution that I tried was to create a (user) cron job to check e.g. every 5 minutes, if the certificate files had changed, and if they had, to copy the certificate files to the podman user's directory, give them the ownership of the podman user and permissions for the user to read them and then restart the container. The copied files were mounted to the container.

Marko
  • 49