Rootless Docker Volume Permissions Issue with User Namespace Remapping and ACLs #51238
Description
Description
I am attempting to harden a rootless Docker setup on Ubuntu 22.04 LTS according to CIS Benchmarks. To achieve this, I've configured containers to run as a non-root user (specifically nobody, UID 65534) and have changed the Docker root directory.
When using user namespace remapping with this setup, the container's nobody user (UID 65534) is remapped to a high UID on the host system (UID 165533).
I used Access Control Lists (ACLs) via setfacl to grant the necessary read/write permissions to this host-remapped UID on my volume mount point:
sudo setfacl -R -m d:m:rwx,m:rwx /home/user/data/docker-data/
sudo setfacl -R -m d:u:165533:rX,u:165533:rX /home/user/data/docker-data/
This setup successfully allows the nobody user inside the container to access directories created manually within /home/user/data/docker-data/ due to inherited default permissions.
However, when running containers using docker compose up -d, Docker creates new directories (e.g., within /home/user/data/docker-data/containers/). These newly created directories have incorrect effective permissions, specifically the mask bit (group class permission) appears to be inadvertently reducing the effective access, often dropping the read permission. This results in permission denied errors for the container's nobody user when trying to access files/directories created by Docker.
Reproduce
- Set up Rootless Docker on Ubuntu 22.04.
- Configure a custom Docker root directory (e.g.,
/home/user/data/docker-data/). - Apply the following ACLs to the volume mount point
sudo setfacl -R -m d:m:rwx,m:rwx /home/user/data/docker-data/
sudo setfacl -R -m d:u:165533:rX,u:165533:rX /home/user/data/docker-data/
- Use a
docker-compose.ymlfile that mounts a volume within the ACL-protected path and runs a service as usernobody:nobody(UID 65534). - Run
docker compose up -d. - Inspect the permissions of the newly created directories (e.g., in
/home/user/data/docker-data/containers/) usinggetfacl. - Observe that the container cannot read or write to files/directories created by Docker due to permission errors.
Expected behavior
The directories created by Docker when using docker-compose up -d should inherit the same permissions as the parent directory, allowing the nobody user to maintain access to the volumes without permission issues.
Actual Behavior
Docker creates directories where the effective mask permission is restrictive, blocking the container's non-root user (remapped UID 165533) from accessing the contents, despite the intended ACL configuration.
The issue persists even when attempting to set a permissive UMask by editing the docker.service file:
[Service]
UMask=0002
docker version
Client: Docker Engine - Community
Version: 28.3.0
API version: 1.51
Go version: go1.24.4
Git commit: 38b7060
Built: Tue Jun 24 15:44:12 2025
OS/Arch: linux/amd64
Context: default
Server: Docker Engine - Community
Engine:
Version: 28.3.0
API version: 1.51 (minimum version 1.24)
Go version: go1.24.4
Git commit: 265f709
Built: Tue Jun 24 15:44:12 2025
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.7.27
GitCommit: 05044ec0a9a75232cad458027ca83437aae3f4da
runc:
Version: 1.2.5
GitCommit: v1.2.5-0-g59923ef
docker-init:
Version: 0.19.0
GitCommit: de40ad0
rootlesskit:
Version: 2.3.4
ApiVersion: 1.1.1
NetworkDriver: slirp4netns
PortDriver: builtin
StateDir: /run/user/1000/dockerd-rootless
slirp4netns:
Version: 1.0.1
GitCommit: 6a7b16babc95b6a3056b33fb45b74a6f62262dd4docker info
Client: Docker Engine - Community
Version: 28.3.0
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.25.0
Path: /usr/libexec/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.37.3
Path: /usr/libexec/docker/cli-plugins/docker-compose
model: Docker Model Runner (EXPERIMENTAL) (Docker Inc.)
Version: v0.1.30
Path: /usr/libexec/docker/cli-plugins/docker-model
scan: Docker Scan (Docker Inc.)
Version: v0.23.0
Path: /usr/libexec/docker/cli-plugins/docker-scan
Server:
Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 21
Server Version: 28.3.0
Storage Driver: overlay2
Backing Filesystem: xfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: true
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
CDI spec directories:
/etc/cdi
/var/run/cdi
Swarm: inactive
Runtimes: runc io.containerd.runc.v2
Default Runtime: runc
Init Binary: docker-init
containerd version: 05044ec0a9a75232cad458027ca83437aae3f4da
runc version: v1.2.5-0-g59923ef
init version: de40ad0
Security Options:
seccomp
Profile: builtin
rootless
cgroupns
no-new-privileges
Kernel Version: 5.15.0-141-generic
Operating System: Ubuntu 22.04.5 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 11.68GiB
Name: ubuntu-harden
ID: b1b63035-c27e-44d9-a739-dcc84d1ba511
Docker Root Dir: /home/user/data/docker-data
Debug Mode: false
Experimental: false
Insecure Registries:
::1/128
127.0.0.0/8
Live Restore Enabled: trueAdditional Info
The only current workaround is to run a script repeatedly to manually fix the file permissions/mask after container creation, which is fragile and undesirable for a hardened setup.