Hello all! While working on podman integration, especially the SELinux part of it, I was wondering why we kept using the host's /run (or its replicated /var/run) location inside containers. And I'm still wondering, 2 years later ;). Reasons: - from time to time, there are patches adding a ":z" flag to the run bind-mount. This breaks the system, since the host systemd can't write/access container_file_t SELinux context. Doing a relabeling might therefore prevent a service restart. - in order to keep things in a clean, understandable tree, getting a dedicated shared directory for the container's sockets makes sense, as it might make things easier to check (for instance, "is this or that service running in a container?") - if an operator runs a restorecon during runtime, it will break container services - mounting /run directly in the containers might expose unwanted sockets, such as DBus (this creates SELinux denials, and we're monkey-patching things and doing really ugly changes to prevent it). It's more than probable other unwanted shared sockets end in the containers, and it might expose the host at some point. Here again, from time to time we see new SELinux policies being added in order to solve the denials, and it creates big holes in the host security AFAIK, no *host* service is accessed by any container services, right? If so, could we imagine moving the shared /run to some other location on the host, such as /run/containers, or /container-run, or any other *dedicated* location we can manage as we want on a SELinux context? I would therefore get some feedback about this proposed change. For the containers, nothing should change: - they will get their /run populated with other containers sockets - they will NOT be able to access the host services at all. Thank you for your feedback, ideas and thoughts! Cheers, C. -- Cédric Jeanneret (He/Him/His) Sr. Software Engineer - OpenStack Platform Deployment Framework TC Red Hat EMEA https://www.redhat.com/