Hacker News Reader

Comment by srvmshr | Hacker News Reader

Please excuse my ignorance. I am aware of how Docker generally operates (at a noob level i.e. containerizing an application & uploading to container public registry for general availability).

Given that understanding, could someone please explain what "rootless" would mean? I want to understand these in simpler terms:)

(Thank you in advance)

View on HN

Docker is running a daemon with root privileges to start all containers. So if your start a container with "docker run -d ...." you talk to a privileged process. That in turn means, all spawned containers can have root privileges (docker run -v /etc/shadow ... to change the root password of your host). "rootless" actually means running a container process as a normal user. (less attack surface because of less permissions). So if you would run "podman -v /etc/shadow" as a normal user, you wouldn't have the permissions needed to open the file.

As simple as possible: Docker ("normally"): run every command inside container with full root permissions on host $root-> Docker -> container Docker/Podman ("rootless"): run every command as the current user $user-> container

Maybe take a look here for a better explanation: https://docs.docker.com/engine/security/#docker-daemon-attac...

The other big piece is capabilities (specifically CAP_SYS_ADMIN) which as I understand it is related but kind of orthogonal to the question of root/rootless.

For example, buildah (the container-building part of podman) is daemonless and can use the fuse-overlayfs storage driver to build containers rootlessly— you appear as root inside the container, but from the outside, those processes and any files created are owned by the original invoking user or some shim UID/GID based on a mapping table.

But critically, this doesn't mean it's possible to just run buildah inside any Kubernetes pod and build a container there, because buildah needs to be able to start a user namespace, and must have the /dev/fuse device mapped in. I believe there continues to be ongoing work in this area (for example Linux 5.11 allows overlayfs in unprivileged containers), but the issue tracking [1] it is closed without really being IMO fully resolved, since the linked article [2] from July 2021 is still describing the different scenarios as distinct special cases that each require their own special sets of flags/settings/mounts/whatever.

[1]: https://github.com/containers/buildah/issues/2554

[2]: https://www.redhat.com/sysadmin/podman-inside-kubernetes

Yup, and based on that mapping table the process inside the container is not allowed to create another namespace and/or fuse-overlayfs. That's why you need to mount /dev/fuse into the container (you might also need cap_sys_admin and cap_mknod). There is another link from RedHat which also explains it:

https://www.redhat.com/sysadmin/podman-inside-container

You can run "capsh --print" to see your current capabilities. And to run a container without any capabilities:

podman run --cap-drop ALL -it fedora capsh --print

Typically, the way a normal Docker installation works is that dockerd (the Docker daemon) is an always-on background service running as root that exposes a socket file with group write privileges owned by the 'docker' group, allowing non-root users to send commands, effectively acting as a privilege-escalation mechanism. There were at least three reasons the daemon needed to run as root, which included needing to modify the host routing table to set up an overlay network, only root being able to create overlay filesystems, and at least some containers themselves having to run as root because they contained files that had to be manipulated in some way by uid 0 in the container.

podman in rootless mode gets around these by using slirp4netns to create pure-userspace overlay networks, fuse-overlayfs to create pure-userspace overlay filesystems (or a driver that can't deduplicate storage on older kernels), and uid/gid mapping in user namespaces to create the illusion inside of a container that an application is running as root when it isn't really root on the host.

Additionally, podman gets rid of the daemon and just uses normal fork/exec of the ephemeral podman process.

The upsides are:

- podman can run entirely in home directories and doesn't need to globally install config files or the container filesystems, making it easier for many users to share the same server.

- Running a malicious or compromised container won't compromise your host (big caveat here is unless it can exploit a vulnerability in user namespaces).

- Users who don't have root at all can still run containers. Note that while this appeared to be true using Docker because you could just be part of the 'docker' group to write to dockerd's socket, effectively this was giving you root.

The biggest downside is the userspace networks and filesystems are slow compared to their in-kernel counterparts, which is why you typically won't see it in any kind of production setting, but minikube is meant to be used as a small-scale mock of production kubernetes run by developers, so it can be a good fit there.

Note that rootless minikube was actually already possible, but way more convoluted than just using rootless podman as the container runtime.

I've seen netavark described as a much faster rootless networking stack. Do you know if that is the case? I know that Podman supports it. Does anything like that exist for storage?

Not an expert at all, but here's how I would simplify it. All corrections are welcome!

Docker has two main components. The daemon (you can think of it somewhat like a server) and the client (application you use to run commands).

When you install docker on your machine, it generally installs both. The daemon is a process that runs on your local machine and runs as root.

Rootless refers to the alternative method (used by podman for instance) to run the daemon as a standard user, and delegate root-level tasks to something else, like systemd for instance.

> Docker has two main components. The daemon (you can think of it somewhat like a server) and the client (application you use to run commands).

Is the daemon what they call the docker-engine? Is this what's available on Linux natively? Rootless makes sense here bc you wouldn't want one docker image able to interfere with another, or even the Linux system that is running the docker runtime/engine.

For Windows/Mac docker solutions, where does the daemon live/exist/run? Inside a virtualized Linux instance?

As I understand it, most of these alternatives to docker-desktop are all just wrappers around a virtualized Linux image running the docker engine/runtime. That's why many of them require a virtualization engine like Virtual Box. So are these no-commercial solutions just wrappers around one or more virtualized Linux runtimes where the docker engine/runtime is running natively?

If all the above is (approx) correct, then "what" is rootless with this announcement? The docker runtime/engine in the virtualized Linux instance?

I thought the docker engine/runtime on Linux was always able to run rootless docker images. So what is the news here if all these non-commercial solutions are just wrappers around the docker engine/runtime running in a virtualized Linux?

Yes for windows and Mac it runs a Linux VM. On windows it can also use WSL2 as the linux vm.

Docker-engine is the daemon built by docker. Podman is an opensource work a like. Docker-engine doesn't support running as a user other than root. Podman does. This announcement says minikube will work with Podman running as not root.

Thanks for clearing that up.

I remember hearing that development of docker-engine was ceasing, but could obviously live on as it was forked. I guess rootless is some of the work that Docker (company) wanted to keep proprietary and out of this open-source project.

Really quite a shame, although understandable from a commercial perspective.

Assuming that these improvements are finding their way back into an open-source project, I'm glad to hear about this work from minikube and Podman.

> I guess rootless is some of the work that Docker (company) wanted to keep proprietary and out of this open-source project.

Rootless mode for Docker is completely FLOSS, and its main contributor (me) has even never worked for Docker (company).

https://github.com/moby/moby/blob/master/contrib/dockerd-roo...

https://github.com/rootless-containers

> Docker-engine doesn't support running as a user other than root. Podman does.

Docker engine does.

It means it uses user namespaces to map a non root user in the top level user namespace (where eg init runs) to a root user inside the container. This allows the container process to run as root inside its user namespace, retaining the full set of capabilities required to call privileged syscalls or access files owned by root.

Docker does all its work in a central daemon running as route. Any docker command you run is just sending messages to that central daemon.

You can see some downsides to this when you do the classic developer setup system of having a docker image with your tools and mounting a volume of your source tree into the container for building. When you build, the build products in your filesystem are owned by root because the code was actually running under the daemon. This can cause all sorts of pain.

When you run something like podman, there's no daemon - it's all just processes running as your user (like any other script) so files created end up on your filesystem owned by you.

It means you don't need to be root to run it.

You can also call docker commands by being part of the docker group IIRC.

Doesn't this have more to do with the daemon that the user executing commands ?

> You can also call docker commands by being part of the docker group IIRC.

Which effectively gives you root on the host.

Which is an horrible practice and has roughly the same attack surface as login as root all the time.

With podman there is no daemon, everything is running as you. The standard setup for docker has a daemon running as root, which means when you start a container it has root privileges.

Reply on news.ycombinator.com