diff options
author | Matthew Heon <mheon@redhat.com> | 2021-03-19 14:55:08 -0400 |
---|---|---|
committer | Matthew Heon <matthew.heon@pm.me> | 2021-03-24 14:24:47 -0400 |
commit | 452decf8a4e02c35413eb8dd691f2d4827972ec2 (patch) | |
tree | a87efe4e2cc06d6ac6ba441ddf540c0af99c7d11 /libpod/container_copy_linux.go | |
parent | 5325957d536be3515fb7a782e4755afca38fca4c (diff) | |
download | podman-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