Share volumes between Podman Systemd services

 December 31, 2023

Since the merge of Quadlet in Podman, I’ve been moving multiple services to Podman Systemd services. I find them to be easy to create, manage, and automate.

I recently migrated a complex system to Podman Systemd, where multiple processes write in a folder, and one process reads the folder’s content. Before the migration, everything worked properly since all the processes were running natively on the machine with the same user. After the migration, there were some permissions issues. This issue allowed me to dive a little more deeply into the whole implementation of SELinux for containers and realize a few interesting things.

Until this point, I’ve always been able to do what I needed by simply using the mount flags (Z and z). The documentation explains that the z option tells Podman to label the content with a shared content label, while the Z option tells Podman to label the content with a private unshared label. So, my thumb rule has always been, if you want to mount the same content in multiple containers use z, otherwise use Z.

While Z works precisely as you can imagine it, z works as described as long as those containers only need to read or edit the files. If one of the containers will create new files, those will not be readable by the other containers. The reason is that although the z configures the SELinux level for the files to be s0, the processes in the container will still run with a SELinux Category set as well, so the files that get created by the process are going to have the same categories, so you’ll find them with something like s0:c496,c555. This SELinux category makes the file unreadable to the processes in the other containers since those processes are running with a different SELinux category set.

Luckily, there is an easy solution for this. To fix the issue, it is enough to add SecurityLabelLevel=s0 under the [Container] section of your Podman Systemd container files. Now, this opens you to a potential issue: all containers will effectively run in the same SELinux context, making the whole system less secure. To avoid this, you can set SecurityLabelLevel as a certain category for certain containers. As long as the set is equal, the containers can read the files created by each other.

To give you a practical example, let’s say we have five containers: A, B, C, D, E.

• A and B need to be able to see each other’s files but isolated from any other container.
• C and D need to be able to see each other’s files but isolated from any other container.
• E need to be fully isolated from any other container and between the various runs of E.

In this case, we can set SecurityLabelLevel in the following way:

• Container A: SecurityLabelLevel=s0:c123,c234
• Container B: SecurityLabelLevel=s0:c123,c234
• Container C: SecurityLabelLevel=s0:c456,c567
• Container D: SecurityLabelLevel=s0:c456,c567
• Container E: no SecurityLabelLevel configured (a random one will be generated at start time)

If you are running Podman without Systemd units, you can use the --security-opt label=level:s0:c123,c234 option, which has the same effect.

I hope this helps you better understand how SELinux and container volumes work together in cases where multiple containers need to share volumes in a controlled way.