volume ownership changes in rootless mode
Greetings, I observe the following strange behavior as regarding volume ownership in rootless mode. I have user oracle with uid 502 and group oinstall with gid 501 both on host system and in my container. I create a volume and change it's ownership as follows: podman volume create data podman unshare chown 502:501 ~/.local/share/containers/storage/volumes/rdata/_data ls -ld ~/.local/share/containers/storage/volumes/rdata/_data drwxr-xr-x 1 200501 200500 0 мар 14 2021 /home/ivans/.local/share/containers/storage/volumes/rdata/_data/ So far so good. I run my test container: podman run --name test --detach --volume rdata:/mnt test And check the volume ownership inside the container: podman exec -it test ls -ld /mnt The owner reported for /mnt is the one configured with --user, when container was built, not oracle:oinstall! I stop the container and check volume owner. It has changed: ls -ld ~/.local/share/containers/storage/volumes/rdata/_data drwxr-xr-x 1 201000 200999 0 мар 14 2021 /home/ivans/.local/share/containers/storage/volumes/phsdata/_data/ I change volume owner again: podman unshare chown 502:501 ~/.local/share/containers/storage/volumes/rdata/_data and run the container using same command: podman run --name test --detach --volume rdata:/mnt test The second time everything is correct: podman exec -it test ls -ld /mnt drwxr-xr-x 1 oracle oinstall 0 Mar 14 2021 /mnt And same outside of container: drwxr-xr-x 1 200501 200500 0 мар 14 2021 /home/ivans/.local/share/containers/storage/volumes/rdata/_data/ If I remove the volume and create it again, then the ownership is again changed to default container user. So expected ownership is set only after second mount of the volume. What might be wrong here? Best regards, -- \ / | | (OvO) | Михаил Иванов | (^^^) | | \^/ | E-mail: ivans@isle.spb.ru | ^ ^ | |
On 9/22/21 03:04, Michael Ivanov wrote:
Greetings,
I observe the following strange behavior as regarding volume ownership in rootless mode. I have user oracle with uid 502 and group oinstall with gid 501 both on host system and in my container.
I create a volume and change it's ownership as follows:
podman volume create data podman unshare chown 502:501 ~/.local/share/containers/storage/volumes/rdata/_data ls -ld ~/.local/share/containers/storage/volumes/rdata/_data
drwxr-xr-x 1 200501 200500 0 мар 14 2021 /home/ivans/.local/share/containers/storage/volumes/rdata/_data/
So far so good. I run my test container:
podman run --name test --detach --volume rdata:/mnt test
And check the volume ownership inside the container:
podman exec -it test ls -ld /mnt
The owner reported for /mnt is the one configured with --user, when container was built, not oracle:oinstall!
I stop the container and check volume owner. It has changed:
ls -ld ~/.local/share/containers/storage/volumes/rdata/_data
drwxr-xr-x 1 201000 200999 0 мар 14 2021 /home/ivans/.local/share/containers/storage/volumes/phsdata/_data/
I change volume owner again:
podman unshare chown 502:501 ~/.local/share/containers/storage/volumes/rdata/_data
and run the container using same command:
podman run --name test --detach --volume rdata:/mnt test
The second time everything is correct:
podman exec -it test ls -ld /mnt
drwxr-xr-x 1 oracle oinstall 0 Mar 14 2021 /mnt
And same outside of container:
drwxr-xr-x 1 200501 200500 0 мар 14 2021 /home/ivans/.local/share/containers/storage/volumes/rdata/_data/
If I remove the volume and create it again, then the ownership is again changed to default container user. So expected ownership is set only after second mount of the volume.
What might be wrong here?
Best regards,
The first time a volume is used with chown the file to the destination directorys permissions if the destination exists, otherwise we chown it to the UID of the default user of the image. We do this with unnamed volumes, but maybe we are doing it also with named volumes which I think would be a bug. Especially if that volume was used in a different container with a different UID.
If I run test container without --volume, then /mnt directory ownership is root:root. So volume ownership is not set to the one on the directory under which it is mounted. Rrgrds, On 22.09.2021 15:41, Daniel Walsh wrote:
On 9/22/21 03:04, Michael Ivanov wrote:
Greetings,
I observe the following strange behavior as regarding volume ownership in rootless mode. I have user oracle with uid 502 and group oinstall with gid 501 both on host system and in my container.
I create a volume and change it's ownership as follows:
podman volume create data podman unshare chown 502:501 ~/.local/share/containers/storage/volumes/rdata/_data ls -ld ~/.local/share/containers/storage/volumes/rdata/_data
drwxr-xr-x 1 200501 200500 0 мар 14 2021 /home/ivans/.local/share/containers/storage/volumes/rdata/_data/
So far so good. I run my test container:
podman run --name test --detach --volume rdata:/mnt test
And check the volume ownership inside the container:
podman exec -it test ls -ld /mnt
The owner reported for /mnt is the one configured with --user, when container was built, not oracle:oinstall!
I stop the container and check volume owner. It has changed:
ls -ld ~/.local/share/containers/storage/volumes/rdata/_data
drwxr-xr-x 1 201000 200999 0 мар 14 2021 /home/ivans/.local/share/containers/storage/volumes/phsdata/_data/
I change volume owner again:
podman unshare chown 502:501 ~/.local/share/containers/storage/volumes/rdata/_data
and run the container using same command:
podman run --name test --detach --volume rdata:/mnt test
The second time everything is correct:
podman exec -it test ls -ld /mnt
drwxr-xr-x 1 oracle oinstall 0 Mar 14 2021 /mnt
And same outside of container:
drwxr-xr-x 1 200501 200500 0 мар 14 2021 /home/ivans/.local/share/containers/storage/volumes/rdata/_data/
If I remove the volume and create it again, then the ownership is again changed to default container user. So expected ownership is set only after second mount of the volume.
What might be wrong here?
Best regards,
The first time a volume is used with chown the file to the destination directorys permissions if the destination exists, otherwise we chown it to the UID of the default user of the image.
We do this with unnamed volumes, but maybe we are doing it also with named volumes which I think would be a bug.
Especially if that volume was used in a different container with a different UID. _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
-- \ / | | (OvO) | Михаил Иванов | (^^^) | | \^/ | E-mail: ivans@isle.spb.ru | ^ ^ | |
On 9/22/21 3:04 AM, Michael Ivanov wrote:
What might be wrong here?
I can confirm this (Fedora 33/ podman 3.3.0). Yes , it's weird. It's overriding the user/group ownership on first run to that of the host user. However, if you do it with a bind mount it works as expected: mkdir ~/mydata podman unshare chown 34:34 mydata/ podman run -it --rm -v ~/mydata/:/mnt httpd bash -----> ls -ld /mnt -----> drwxrwxr-x. 2 backup backup 4096 Sep 22 13:40 /mnt -----> grep backup /etc/passwd -----> backup:x:34:34:backup:/var/backups:/usr/sbin/nologin -- Jorge
participants (3)
-
Daniel Walsh -
Jorge Fábregas -
Michael Ivanov