[some0x80070005]

It’s great that podman serves a good role for you, and I’m not going to argue that. My points:

1. Docker containers absolutely can be run without root. Yes, it’s not the default policy, but containers can have a user ID. If you are referencing the daemon-less root-less nature of podman, that’s a clear advantage of podman vs Docker. 2. Docker containers also have a restart policy which I use to also have them startup on machine reboot. By graceful, you must mean sending SIGTERM to the containers which Docker does as well.

Perhaps podman does these things better, but I want to point out that Docker does have many features for better or for worse.

[akerl_]

When people talk about “rootless” in this context, they’re not talking about “launching containers whose process runs as non-root”. The innovation of podman is that a non-root user can “safely” be given permission to launch containers whose maximum permissions are “the perms that user has”.

Docker doesn’t have this functionality: the daemon runs as root, and anybody who is granted access to launch containers by invoking Docker commands can inherently access root-level privileges. The most mundane way to do this is to launch a container with the host’s namespaces instead of generating new ones.

[nonameiguess]

It's not the default setup and not trivial to do, but Docker has had the ability to run the daemon as a non-root user for a few years. The standard .deb and .rpm packages even include scripts to automate the transition for you on Debian and RedHat Linux variants. See https://docs.docker.com/engine/security/rootless/

The only thing podman gives you that docker itself can't is running without a daemon at all.

[PhilippGille]

> root-less nature of podman

I see this repeated a lot, but it's not the default, its has to be explicitly configured: https://github.com/containers/podman/blob/v3.3.1/docs/tutori...

And in addition to the known upsides, there are some lesser known downsides:

1. There are feature limitations with it: https://github.com/containers/podman/blob/v3.3.1/rootless.md

2. There are security implications, quoting Arch Wiki:

> Warning: Rootless Podman relies on the unprivileged user namespace usage (CONFIG_USER_NS_UNPRIVILEGED) which has some serious security implications, see Security#Sandboxing applications for details.

Also worth noting that Docker itself has a rootless mode as well by now: https://docs.docker.com/engine/security/rootless/

I'm happy that there are Docker alternatives, but I have the feeling that podman has been hyped a lot recently and many articles and comments give the impression that it's more secure by default and without any downsides.

[CameronNemo]

Why should I trust the Arch wiki? People like Christian Brauner think the value of not running as UID 0 outweighs the increased attack surface from the user namespace.

https://people.kernel.org/brauner/runtimes-and-the-curse-of-...

[hda111]

Thanks for writing this. He knows what he is talking about. One of the LXC maintainers.

[_ea1k]

AFAIK, the default packaging on Fedora enables rootless podman without additional configuration.

[maxdamantus]

Probably worth pointing out that docker has had a "userns-remap" option for quite a while, which causes all containers to run in a separate user namespace where UID 0 inside remaps to something else outside, so theoretically a user with access to the docker daemon isn't able to view the outside filesystem as root[0].

I have gone back and forth with podman. At some point it seemed to sometimes get into a funny state where I would simply delete everything[1] to fix it. On all systems where I run docker, I make sure to have "userns-remap": "default" in /etc/docker/daemon.json. Haven't looked into the rootless mode yet, but I was aware a few years ago that they were working on it.

[0] Without remapping root inside a different namespace, anyone with access to the docker daemon can access the outer root filesystem as root using a command such as `docker run --rm -it -v /:/oops alpine`

[1] Amusingly, the simplest way to do this was by using root to run `rm -rf` on my own ~/.local/share/containers/ directory, since the containers used UIDs other than my own (ones that are part of my subuid range)

[kblev]

Thanks