Hi everyone, I'm Pete. I've been following the OpenClaw project with great interest for a few weeks now, especially with my focus on self-hosting and privacy. I'm still getting my feet wet with containers, so I hope this question isn't too basic.
I'm in the planning stages of deploying OpenClaw on my home server, and my number one priority is security. I've been reading about the principle of least privilege, and it got me thinking. The official Docker image examples I've seen all seem to run as root inside the container. That makes me a bit nervous, even with the container being isolated from the host.
So, my question is: has anyone here successfully run the OpenClaw agent under a non-root user *inside* the container itself? I'm looking for a step-by-step approach, if possible.
I understand I might need to create a user in the Dockerfile and use the `USER` directive, but I'm worried about permissions. Specifically, which directories or volumes would the agent need write access to? Would it need to bind to privileged network ports? I want to make sure I don't break the agent's functionality by being overly cautious.
If you've done this, could you walk me through the exact changes you made? I'd really appreciate knowing about any pitfalls you encountered, like permission errors for the config file, data storage, or communication with the OpenClaw server. Maybe there are specific capabilities that still need to be dropped even as a non-root user inside the container?
I'm also wondering if running as a non-root user inside the container works well with other hardening steps, like setting a read-only filesystem for everything except the necessary data volume. Any guidance would be a huge help for my setup.
Good question. I run mine as a non-privileged user. You'll need to set permissions for /dev/stdout, /dev/stderr, and wherever you mount your config/log volume if you use one. The agent doesn't need any privileged ports.
The tricky part is if you're using any kernel-level event monitoring. That might require specific capabilities even as a non-root user. Check the Docker run flags for those.
watch and learn
You're on the right track with your concerns about the default root user. The official examples are, frankly, a compliance gap. I'd extend user362's point about permissions: you must also pre-create and chown the directories the agent uses for its runtime state, not just logs and config. This is often missed.
A step-by-step approach in a custom Dockerfile would involve creating a user and group, then explicitly setting ownership on every volume mount path the agent needs. Don't forget /tmp if the agent uses it. The agent binary itself likely doesn't need setuid bits, but you must verify the static data it reads is globally readable.
The real audit trail consideration is whether dropping root privileges interferes with the agent's ability to generate cryptographically signed event logs. If the agent uses a hardware security module or a key file, that key's permissions become critical.