You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
But, if you create them both under the same pod so that they share the volume:
term1$ mkdir -p ~/tmp/podmates
term1$ podman pod create -v ~/tmp/podmates:/tmp:Z foo
term1$ podman run --rm -it --pod foo alpine
/ # echo 'hello from term1' > /tmp/test
term2$ podman run --rm -it --pod foo alpine
/ # echo 'hello from term2' >> /tmp/test
term3$ cat ~/tmp/podmates/test
hello from term1
hello from term2
term3$ stat ~/tmp/podmates
…Context: system_u:object_r:container_file_t:s0:c171,c253…
Thus, although this bind-mounted directory got an unshared SELinux label due to the :Z flag on the pod's --volume option, both containers were able to write a file into it.
This is an important feature worth documenting, both for its own sake and to avoid inadvertently breaking it in the future. If it did not behave this way, I would instead be here advocating for a third mount flag to give this behavior. (I was fully prepared to propose ℤ. 🤓)
Describe the results you received
Permission denied error with wholly separate containers, but no error with containers sharing a pod.
Describe the results you expected
It does work as expected, today. This merely needs to be documented and protected from inadvertently changing in the future by a regression test.
Issue Description
The documentation for the :Z mount flag claims, "Only the current container can use a private volume," but that ignores the pod case.
Steps to reproduce the issue
Here's a simple two-terminal test proving the documentation partially accurate:
But, if you create them both under the same pod so that they share the volume:
Thus, although this bind-mounted directory got an unshared SELinux label due to the :Z flag on the pod's
--volume
option, both containers were able to write a file into it.This is an important feature worth documenting, both for its own sake and to avoid inadvertently breaking it in the future. If it did not behave this way, I would instead be here advocating for a third mount flag to give this behavior. (I was fully prepared to propose ℤ. 🤓)
Describe the results you received
Permission denied error with wholly separate containers, but no error with containers sharing a pod.
Describe the results you expected
It does work as expected, today. This merely needs to be documented and protected from inadvertently changing in the future by a regression test.
podman info output
Podman in a container
No
Privileged Or Rootless
Rootless
Upstream Latest Release
No
Additional environment details
Additional environment details
Additional information
Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting
The text was updated successfully, but these errors were encountered: