Extend `Chowning Volume Mounts` (`:U`) to Allow Custom Ownership Specification

[0xF4CED]

Feature request description

Currently, we have the :U option to chown the source of a mountpoint to match the default UID and GID used within the container. This option is especially useful in the context of --userns=auto. Some images however have a bad practice of not specifying their runtime user in their image but e.g. handing over from root to their runtime user in their entrypoint script. This can result in defunctional run states where the container service can't function correctly because of inadequate permissions of e.g. mounted configuration files.

Suggest potential solution

An elegant solution would be to extend the :U parameter by making it possible to additionally supply something like :U=$UID:$GID as in :U=82:82 or :U=www-data:www-data to set specific ownership, overriding the image's default user.

Have you considered any alternatives?

Manually adjusting ownership. This however is an unmaintainable approach, especially when relying on --userns=auto.

Additional context

Example image affected: Nextcloud (Dockerfile, entrypoint.sh)

[Luap99]

Not against this feature but in my experience containers that switch users will chown the volume to the correct user in the entrypoint as well. But I see that this does not seem to be the case with your linked nextcloud image.

[rhatdan]

Does podman run --keep-id:uid=82,gid=82 help

[0xF4CED]

I mean, it can circumvent the defunctional state, but it doesn't achieve the desired end result of running the service in a unique user namespace.

[rhatdan]

I don't think we should abuse --volume on this, but force this on --mount We currently allow you to specify the UID and GID for devpts, we just need to extend this to bind and glob mounts.

[0xF4CED]

Makes sense, I guess. From a user's perspective, I would most likely expect or look for it in relation to --volume, though I would be more than happy with support for it through --mount.

[Luap99]

I thought we use the same code for --volume and --mount as far as option parsing is concerned so I don't think it matters either way.

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.

[giuseppe]

if the image manually changes the user at runtime and doesn't take into account volumes., to me this looks like an issue in the image.

Is this a common pattern? Do you know of any other image doing the same?

[0xF4CED]

Thank you, for your consideration. Yes, I had problems like this with other images before, but can't remember which ones. I agree that this should be handled better by the image. However, I think they simply only ever used docker as rootfull daemon and never ran into problems with that (which is a common theme). Maybe they even had to adjust ownership once, but with --userns auto, it's a recurring task. It is my understanding that using --userns auto should be encouraged and become best practice with podman whenever possible. Giving users the power to overcome obstacles like this with a feature like the proposed one could help promote adoption.

[rhatdan]

What would you expect :U=82:82 to do chown -R 82:82 VOLUME inside of the containers user namespace?

[0xF4CED]

Yes, exactly.

[rhatdan]

What is the default user within the container in this case? root?

[0xF4CED]

Yes (Dockerfile, entrypoint.sh) And it seems like I have to correct myself: The image does adjust ownership of the volume but not at runtime, which doesn't become a problem with docker because docker copies the image's mounted directory including ownership to the host's bind mount point, which is not the case with podman of course. From the Dockerfile:

chown -R www-data:root /var/www