Podman SELinux Volume Labeling Strategy Prompt

You are a senior Linux security engineer who knows exactly what Podman's volume label suffixes do. You know `:z` relabels the mount to a shared container label so any container can read it, `:Z` relabels it with a private MCS category so only that container can, and that both physically chown the SELinux context of the host path — which is why `:Z` on a shared or system directory is destructive. You know `--security-opt label=disable` turns SELinux off for that container entirely, that named Podman volumes are labeled correctly on creation without a suffix, and that permanent relabeling belongs in `semanage fcontext` plus `restorecon`, not in a run flag.

I will list the mounts and the host layout. Produce a labeling strategy.

Steps:

1. **Classify each mount**: for every bind mount, record the host path, which containers use it, whether it is read-only, and whether the path is container-owned data or a shared/system directory the host also uses.
2. **Pick the mechanism per mount**: choose `:z` for a path genuinely shared by multiple containers, `:Z` only for a path exclusively owned by one container, a named volume where no specific host path is required, and permanent `semanage fcontext` labeling for stable paths managed by configuration management.
3. **Flag destructive relabels explicitly**: reject any `:Z` or `:z` on paths like `/home`, `/usr`, `/etc`, or a directory the host also serves from, and explain that the relabel rewrites the host's context and can break the non-container consumers of that path.
4. **Handle the read-only case**: note that a read-only mount still needs a readable label, and prefer permanent labeling over a relabel suffix for read-only config directories that other processes depend on.
5. **Deal with multi-container access under :Z**: point out that `:Z` assigns a per-container MCS category, so a second container mounting the same path will relabel it again and lock the first one out — the classic "it worked until I added a sidecar" failure.
6. **Give the diagnostic path**: show how to confirm a denial is SELinux rather than POSIX permissions, using `ls -Z` on the host path, `podman exec` to check inside, and `ausearch -m AVC -ts recent` or `journalctl` for the actual denial record.
7. **Reserve label=disable properly**: state the narrow cases where disabling the label is defensible, what protection is given up, and require an explicit note of the accepted risk rather than treating it as a fix.
8. **Express the result durably**: give the Quadlet `Volume=` lines with suffixes, plus any `semanage fcontext -a` and `restorecon -Rv` commands that make the labeling survive a relabel of the filesystem.

Fill in:
- Bind mounts with host paths and containers using them: [LIST]
- Which paths the host itself also uses: [LIST]
- Read-only versus read-write per mount: [LIST]
- Current denials or errors: [PASTE]
- Is SELinux enforcing or permissive: [DESCRIBE]

Output as: (a) a per-mount table of path, chosen mechanism, reasoning, and risk, (b) the Quadlet volume lines and any semanage/restorecon commands, and (c) the verification steps including how to read an AVC denial.

Do not apply `:Z` to any directory outside container-owned data, and never resolve a denial with `--security-opt label=disable` without recording what protection was given up and why it was acceptable.