search

containers / podman

Podman: A tool for managing OCI containers and pods.
https://podman.io
Apache License 2.0
23.73k stars 2.41k forks source link

Support enabling idmap (or chown) globally #16250

Open klausenbusk opened 2 years ago

klausenbusk commented 2 years ago

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind feature

Description

userns can be set to auto in containers.conf, which is very useful to transparently enable this feature. This causes issues with volume ownership, which can be fixed by using the idmap or chown (U) option when attaching the volume to the container. Unfortunately, the client (gitlab-runner in my case) must be modified to make passing these options possible.

It would be useful if idmap (or chown) could be enabled globally, so userns=auto can be used without requiring changes to the client.

github-actions[bot] commented 1 year ago

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

rhatdan commented 1 year ago

I could see doing idmapping for volumes since this is not destructive and time consuming. Where as chowning would hurt you on both. idmapping currently only works with root containers.

@giuseppe WDYT?

giuseppe commented 1 year ago

I think that having a global setting to override the default options for volumes could be helpful

github-actions[bot] commented 1 year ago

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

github-actions[bot] commented 1 year ago

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

giuseppe commented 1 year ago

we have a :idmap option now. I am not sure whether it should be a global setting though, it is safer if it is specified for the individual mount. It should be used only when needed, e.g. volumes shared among different containers with different mappings, not a global setting (potentially a security issue since --userns=auto can then create files owned by root even if running in a user namespace)

giuseppe commented 4 months ago

anything against closing this issue?

As pointed out in the last comment, it is safer when the flag is opt-in, as it cancel the benefits of running in a user namespace for volumes, since files will be created on the host with the same UID/GID as inside the user namespace. It is better to use it with care only when necessary.

AlbanBedel commented 18 hours ago

I find the usability is still problematic. Without idmap the data in the volume is only usable for the lifetime of the first container using it, which kind of defeat the whole purpose of using a volume at all. As a user I really want defaults where volumes are re-usable across different containers. The security argument is also not fully valid as uid ranges are re-used, so once the original container is gone another unrelated one will sooner or later get an overlapping uid range with unpredictable results.

It might be better if the volumes had a "storage idmap" property that define how the uid seen by containers should be mapped to uid in the backing filesystem. Containers using the volume could then always be configured to get the correct view independently of which user namespace they use. Assuming the storage uid ranges don't overlap with the one used for the containers we would also get better security as volumes data could only be accessed if explicitly mapped.