summaryrefslogtreecommitdiff
path: root/libpod/container_copy_linux.go
diff options
context:
space:
mode:
authorMatthew Heon <mheon@redhat.com>2021-03-19 14:55:08 -0400
committerMatthew Heon <matthew.heon@pm.me>2021-03-24 14:24:47 -0400
commit452decf8a4e02c35413eb8dd691f2d4827972ec2 (patch)
treea87efe4e2cc06d6ac6ba441ddf540c0af99c7d11 /libpod/container_copy_linux.go
parent5325957d536be3515fb7a782e4755afca38fca4c (diff)
downloadpodman-452decf8a4e02c35413eb8dd691f2d4827972ec2.tar.gz
podman-452decf8a4e02c35413eb8dd691f2d4827972ec2.tar.bz2
podman-452decf8a4e02c35413eb8dd691f2d4827972ec2.zip
Ensure manually-created volumes have correct ownership
As part of a fix for an earlier bug (#5698) we added the ability for Podman to chown volumes to correctly match the user running in the container, even in adverse circumstances (where we don't know the right UID/GID until very late in the process). However, we only did this for volumes created automatically by a `podman run` or `podman create`. Volumes made by `podman volume create` do not get this chown, so their permissions may not be correct. I've looked, and I don't think there's a good reason not to do this chwon for all volumes the first time the container is started. I would prefer to do this as part of volume copy-up, but I don't think that's really possible (copy-up happens earlier in the process and we don't have a spec). There is a small chance, as things stand, that a copy-up happens for one container and then a chown for a second, unrelated container, but the odds of this are astronomically small (we'd need a very close race between two starting containers). Fixes #9608 Signed-off-by: Matthew Heon <mheon@redhat.com>
Diffstat (limited to 'libpod/container_copy_linux.go')
0 files changed, 0 insertions, 0 deletions