Coming from docker-compose for my homeserver, I am figuring out the changes to make to my compose file to make it work via podman-compose.
The one thing I am really a bit reluctant about is adding :Z or :z to all my mounts, since :z will change actual personal data (my media, documents, photos) irreversibly.
For the folder that will contain the container configuration, I can simply use :Z (capital version). That I am not too worried about.
However to mount my own personal data folders (/var/mnt/media and /var/mnt/users, these are 2 separate SSD drives), I would need to use :z (small version) to give multiple containers access. Is there an alternative that is perhaps more safe?
For example, Jellyfin own documentation on podman only uses capital :Z for the container config folders and a bind mount without flag for the actual media folder:
I don’t understand why the SELinux flags are not necessary for the /path/to/media mount? The documentation even says you can use ro=false to give the container write access (which is necessary for my use-case).
Pretty much every documentation online tells me I should use (small):z in this case, so this type of bind mount is maybe no longer supported?
Or perhaps the issue is that you can’t add identical bind mounts to other containers?
Or perhaps such bind mounts are not supported via podman-compose?
Just guessing here, I have been reading all morning and really trying to understand how to properly mount my media folders (for multiple containers) and other personal data folder (for multiple containers), safely.
If the directories in question are mountpoints (/var/mnt/media and /var/mnt/users), then you could set the SELinux context at mount time for all files under the mountpoint with something like context=system_u:object_r:container_var_lib_t:s0. If done in this way, the existing files should not be altered. The mount option should just mask the real context that is set on the files. I’m not sure what context new files would receive, however. There is a defcontext=... option that might determine what context new files get, but I’ve never used it. The details are in the mount man page.
Do you mean I add the context flag to my mount points in /etc/fstab?
That’s a very interesting idea!
I’ve been going through man pages. While context is mentioned together with other things like fscontext, the possible values are not clear. It seems to be something not properly documented. At least not for someone with my knowledge level
I’ve also read this:
Which says i should use defcontext. I’m considering to use your example, but with defcontext instead of context.
If there is more insight as to what options to add, would be much appreciated.
As soon as it comes to SELinux I believe I’m a little in over my head…
For the trivial use-cases I’ve needed it (VFAT file systems that don’t support SELinux attributes or a few cases where I just wanted to force the OS to see the same context for all files under a mountpoint), just the context=... has been adequate. I’ve never messed with defcontext=.... Good luck!
Edit: Looking at that documentation page you found, it doesn’t look like defcontext=... is what you want. IIUC, it is applied for reads, whereas what I was looking for was something to determine what would be set for writes. Maybe just context=... is enough.
context: causes every file on the filesystem, and the filesystem itself, to be labeled with the specified security context. The /proc/self/attr/fscreate API discussed above is ignored for the filesystem. This overrides existing labeling behavior, changing it to mountpoint labeling. Filesystem labels are read-only to the user with this option, although policy-specified labeling transitions still operate on filesystems with EA security labeling support.
fscontext: sets the label of the aggregate filesystem (that is, the filesystem itself) to the specified security context. This allows finer-grained control of filesystems by allowing their labels to be set on a per-mount basis rather than on a per-fs type basis specified in a policy. As the context option also implements this functionality, the two options cannot be used together. This option works only for filesystems with EA security labeling support. Aggregate filesystem security contexts are used for access control decisions made during file creation within a specific filesystem, mounting and unmounting of filesystems, accessing filesystem attributes and relabeling the filesystem itself.
defcontext: sets the default security context for unlabeled files, instead of the value specified in the policy. As with the fscontext option, it works only for filesystems with EA labeling support and is not valid if context has been specified, as it too implements this functionality.
I added context to my mount options in fstab. I tried with the attributes after context= in double quotes and without:
## Mount the filesystem for users data
UUID=b4509ab8-f22c-42c5-895d-3394a0bce943 /var/mnt/users btrfs context=system_u:object_r:container_var_lib_t:s0,defaults,noatime,compress-force=zstd:3 0 0
## Mount the filesystem for media data
UUID=8791ccad-5a93-4d13-a374-4259473d52e4 /var/mnt/media btrfs context=system_u:object_r:container_var_lib_t:s0,defaults,noatime,compress=zstd:1 0 0
I always get
mount: /var/mnt/users: wrong fs type, bad option, bad superblock on /dev/sda1, missing codepage or helper program, or other error.
dmesg(1) may have more information after failed mount system call.
mount: /var/mnt/media: wrong fs type, bad option, bad superblock on /dev/sdc, missing codepage or helper program, or other error.
dmesg(1) may have more information after failed mount system call.
Works fine when I remove context from mount options… Now I am really stuck.
EDIT:
It looks like this works, moving context... to the end of the mount options:
That’s very odd. I’ve never noticed that bug before. It is probably worth reporting somewhere. I’m sure it shouldn’t do that.
BTW, defaults isn’t necessary when you have other options that you can place in that field of the fstab file. defaults is only necessary as a placeholder to align the remaining fields when you have no other mount parameters that you want to set explicitly.