Mounting /var/run/docker.sock looks like a rootkit

[abitrolly]

https://github.com/pewdiepie-archdaemon/odysseus/commit/b3e186746ac5052728058b332b36720d061d04d3 exposes /var/run/docker.sock to containers. If I understand it right, that gives API access to rootful Docker daemon, which can potentially mount and any other directory to any rogue script that command it.

It looks like this makes Odysseus insecure against different rogue libs and info stealers.

[entitycs]

You have a point. I'll need further justification, as a dockered ollama user who has no issue currently communicating with the models. I am fine with managing those instances directly through ollama.

[alteixeira20]

I think this concern is valid, even if I would frame it less as “rootkit” and more as a high-trust host-control boundary.

Mounting /var/run/docker.sock into a container is not a small permission. In a typical rootful Docker setup, access to the Docker socket effectively gives the process the ability to control the Docker daemon, start containers, mount host paths, and potentially reach host files through newly created containers. So if Odysseus or any dependency running inside the container can reach that socket, the security model is much closer to “trusted host operator tool” than “isolated app container”.

I think the useful question is whether this is required for the default deployment path.

My preference would be:

1. Do not mount the Docker socket by default unless Odysseus cannot function without it.
2. If it is only needed for model/server management, make it an explicit opt-in profile or documented advanced mode.
3. Add a clear warning in the Docker docs that mounting the socket gives Odysseus broad control over the host Docker daemon.
4. Prefer narrower alternatives where possible: direct Ollama/vLLM/OpenAI-compatible endpoints, user-configured model URLs, or a small dedicated sidecar/proxy with a limited API instead of raw Docker socket access.
5. If socket access remains supported, gate any feature that depends on it behind explicit configuration so users know they are enabling a host-level management capability.

This does not mean Docker integration is wrong. It just means the default should be conservative. Users who want Odysseus to manage containers can opt in, but users who only want to connect to an existing Ollama/vLLM server should not need to expose the host Docker daemon to the app container.