The default in the docker-compose file is to mount the docker.socket.
This is considered dangerous. As far as i now. Access to the socket is like root access.
https://www.lvh.io/posts/dont-expose-the-docker-socket-not-even-to-a-container.html
https://stackoverflow.com/questions/40844197/what-is-the-docker-security-risk-of-var-run-docker-sock
https://docs.docker.com/engine/security/https/#secure-by-default
https://docs.docker.com/engine/security/security/#docker-daemon-attack-surface
Are you using the Docker image (as described at https://github.com/sharelatex/sharelatex/wiki/Quick-Start-Guide), or some other method of installing ShareLaTeX Community Edition?
docker-image: https://github.com/sharelatex/sharelatex-docker-image
docker-compose: https://github.com/sharelatex/sharelatex/blob/master/docker-compose.yml
I changed mine and it works without the socket.
the latest docker image
For what is the socket needed?
Thank you in advance :)
Thanks for getting in touch. In the Server Pro edition, we use 'sibling' containers to compile projects --- that is, the CLSI service that manages the compiles runs in a container, and that CLSI service also starts new sibling containers to actually run the compiles. This means that the CLSI service needs access to the docker socket; this does give it more privilege than would be ideal, but it means that it can run the compiles themselves with an additional layer of isolation, which is still a win overall. I think you're right that it's not needed in the Community Edition right now, but it is needed in Server Pro, and we are planning to make the Community Edition use the same approach in the not too distant future.
While docker is not too be considered a (secure) layer of isolation, you are effectively destroying that isolation with the docker.sock backdoor. The fact that the backdoor is added to a user facing service (thus the most likely area to be attacked) just makes this an incredibly irresponsible decision. docker.sock is not a single purpose file, own it and you own the entire host machine.
This ticket should be reopened and docker.sock should be removed as a dependency. Having a backdoor for a simple convenience is never a "win overall".
We're re-opening this issue, and plan to change the default configuration so that the docker socket is not mounted into the overleaf container. This will mean that Server Pro admins will need to mount the socket explicitly if they want to use the Sibling Containers feature.
In the meantime, instance admins can remove this line from their docker-compose file (https://github.com/overleaf/overleaf/blob/master/docker-compose.yml#L22), to un-mount the docker socket.
We have updated the example docker-compose file to _not_ mount this socket by default: https://github.com/overleaf/overleaf/pull/699/files