Did Docker 28 change how named volumes are labeled with SELinux MCS? Cross-container socket sharing now broken

Docker Engine General
, ,
1

Hi all,

I’m hoping someone can help clarify something I’ve run into after upgrading to Docker 28.x on a RHEL-based system with SELinux enforcing.

What I’m seeing:

  • On Docker 27.x, named volumes (used for things like MariaDB UNIX sockets in mailcow) were labeled as :s0 (no MCS), and cross-container socket sharing worked fine with SELinux enforcing.
  • After upgrading to Docker 28.x, the same named volumes are now labeled with an MCS context (e.g., :s0:c123,c456), and SELinux blocks access from other containers with different MCS labels—even though the policy allows container_t to access container_file_t.
  • The :z/:Z options only seem to work for bind mounts, not named volumes (Docker docs), so I can’t use them to fix the labeling for named volumes.

I’m not sure if I’m missing something, if this is a new intentional security feature, or if there’s a recommended way to handle this.
I haven’t found any clear mention of this change in the Docker release notes or documentation, and I’m surprised because it seems like it would break a lot of multi-container setups that rely on shared UNIX sockets.

Has anyone else run into this, or is there any official info on this change?
Is there a way to control the MCS labeling for named volumes, or is switching to a bind mount with :z now the only option for SELinux enforcing setups?

Thanks for any clarification or pointers—just trying to understand if this is expected behavior or if I’m missing something obvious.

Paul

2

I see that you already started a discussion in the Moby project: When did Docker start labeling named volumes with container MCS context for SELinux, and is this documented? · moby/moby · Discussion #49933 · GitHub

I would have suggested to either open a discussion or raise an issue in the Moby project.

You can check the release notes for Docker 28.x.: https://docs.docker.com/engine/release-notes/28/.
Make sure to follow the links to referenced GIthub milestones in case the release notes don’t mention it.