Yes; the bug only exists if the user can set annotations.
I tried to think more about why my mental model broke down on your scenario. I tested it, and indeed, it seems to work. But I'm confused *why* it does work. My understanding was that the container root was in some namespace and therefore would have the access of a regular user to the host filesystem.
If I try to mount a filesystem using podman, here is what I get (which is what I expected):
# mkdir /tmp/somedir
# podman run -it -v /tmp/somedir:/somedir busybox sh
/ # ls /somedir/
ls: can't open '/somedir/': Permission denied
If I try to do the same experience suggested by your pod with podman, here is what I get:
# podman run -it -v /etc:/etc busybox sh
/ # passwd
passwd: unknown uid 0
This is what I expected. So why is it different with your example?
Julio,
Yes; the bug only exists if the user can set annotations.
I tried to think more about why my mental model broke down on your scenario. I tested it, and indeed, it seems to work. But I'm confused *why* it does work. My understanding was that the container root was in some namespace and therefore would have the access of a regular user to the host filesystem.
If I try to mount a filesystem using podman, here is what I get (which is what I expected):
# mkdir /tmp/somedir /somedir busybox sh
# podman run -it -v /tmp/somedir:
/ # ls /somedir/
ls: can't open '/somedir/': Permission denied
If I try to do the same experience suggested by your pod with podman, here is what I get:
# podman run -it -v /etc:/etc busybox sh
/ # passwd
passwd: unknown uid 0
This is what I expected. So why is it different with your example?