pass flag required with podman and selinux

[glehmann]

Signed-off-by: Gaëtan Lehmann [email protected]

[stormi]

Could you explain the rationale behind the change in the commit message?

I've seen this :Z in the past and I think it was a workaround of an issue which was not the best solution and for which we found a better solution afterwards, but my memory might fail me.

CC @ydirson

[glehmann]

with a default install of fedora 41 workstation, the container wasn't able to access the local directory mounted in the container.
This is the normal behavior with selinux — see containers/podman#3683

references:
https://docs.docker.com/reference/cli/docker/container/run/#volumes-from
https://docs.podman.io/en/v4.4/markdown/options/volumes-from.html
https://unix.stackexchange.com/questions/651198/podman-volume-mounts-when-to-use-the-z-or-z-suffix

[ydirson]

I've seen this :Z in the past and I think it was a workaround of an issue which was not the best solution and for which we found a better solution afterwards

That does not sound unlike the discussion we had when I added podman support, but that was likely about another mount modifier.

references: https://docs.docker.com/reference/cli/docker/container/run/#volumes-from https://docs.podman.io/en/v4.4/markdown/options/volumes-from.html

Curiously only Docker seem to mention capital "Z"

https://unix.stackexchange.com/questions/651198/podman-volume-mounts-when-to-use-the-z-or-z-suffix

That SE post makes me wonder why we would want that "private" behavior, we likely don't want any "last caller wins" situation. Lowercase "z" ought to be sufficient, right?

[glehmann]

That SE post makes me wonder why we would want that "private" behavior, we likely don't want any "last caller wins" situation. Lowercase "z" ought to be sufficient, right?

z also works. It's just that it doesn't need to be shared, so the more restrictive one seemed more appropriate.
It doesn't make much difference for our use case.

[ydirson]

It doesn't make much difference for our use case.

The script can be run concurrently, to build several packages and/or an interactive sessions at the same time, and we don't want a new run to interfere with those previously launched but not terminated.