Master container should honor DOCKER_HOST variable

[niektoniekde]

Master cointainer should honor DOCKER_HOST variable for connections to docker daemon through socket. There is race condition in environments where SELinux and docker's userns-remap features are enabled because of need for socket with right UID/GID and SELinux context. This can be easily done with systemd socat service.

Mentioned race condition happens when containers are already started and docker creates directory in place where "userns" socket should be created by systemd socat service because host path is defined as volume. Thus socat service will fail immediately and master container after some time without being able to connect to docker daemon.

Steps to reproduce

1. set DOCKER_HOST in environment to custom "unix:///" path

Expected behavior

1. Master cointainer should use defined path in DOCKER_HOST variable.
2. Destination in DOCKER_HOST path can be overlayed as whole host dir to container dir.

Actual behavior

Master container ignores defined path in DOCKER_HOST and refuses to start because there is no access to docker daemon as it probably uses hardcoded path to docker socket.

Other information

Systemd socat service example

[Unit]
Description=Docker userns socket service
Requires=docker.service
After=docker.service

[Service]
Restart=always
Environment=SOCK_UID=100000000
Environment=SOCK_GID=100000000
Environment=SOCK_MODE=0660
Environment=SOCK_DIR=/run/docker-userns
ExecStartPre=/usr/bin/mkdir -p ${SOCK_DIR}
ExecStartPre=/usr/bin/chown ${SOCK_UID}:${SOCK_GID} ${SOCK_DIR}
ExecStart=/usr/bin/socat UNIX-LISTEN:${SOCK_DIR}/docker.sock,user=${SOCK_UID},group=${SOCK_GID},mode=${SOCK_MODE},fork UNIX-CLIENT:/run/docker.sock
ExecStartPost=/usr/sbin/restorecon -R ${SOCK_DIR}

[Install]
WantedBy=multi-user.target

Path /run is tmpfs and it doesn't matter who or what will create directory for docker "userns" socket. If it is docker daemon when processing volumes definition or systemd socat service because whole dir content will be overlayed and socket will be created to this overlay in any case. Ofc it is important to keep permissions consistent with remap UID/GID ranges and to have SELinux context set properly.

I tried to use WATCHTOWER_DOCKER_SOCK_PATH or DOCKER_SOCK_PATH env vars with no impact at all.

[szaimen]

Hi, thanks for bringing this up!

Unfortunately, this looks like a very edgy use case.

So I will not work on this.

However I will monitor the requests for this feature going forward and added it to #5251 in the meantime.

[niektoniekde]

Thanks for your answer but I don't understand how security is edgy in any way. Hovever will you accept pull request if I'll find time to work on such feature?

[szaimen]

Can you please check first if you can make it work with https://github.com/nextcloud/all-in-one?tab=readme-ov-file#are-there-known-problems-when-selinux-is-enabled or https://github.com/nextcloud/all-in-one/tree/main/manual-install? See https://github.com/nextcloud/all-in-one/blob/main/manual-install/latest.yml

[niektoniekde]

Issue here isn't that I can't deploy and use Nextcloud AIO. I have it running but I have to deploy work-around to make it work with all security features enabled. IMO proper solution is to provide environment variable to be able to configure how to connect to docker daemon but I understand it's not worth doing so in case it is hard-coded at many places in codebase.

So I'll utilise WA as I did until now if there are no more requests for this functionality.

[szaimen]

Just to mention it, we have the so called "manual install" avaible for more restricted environments. See https://github.com/nextcloud/all-in-one/tree/main/manual-install and https://github.com/nextcloud/all-in-one/blob/main/manual-install/latest.yml

[niektoniekde]

Well I wanted to avoid manual install as it seems to be a lot of work but maybe it's better approach as it will be more deterministic when used within IaC. Thanks for your time and patience.