Say What Now?

Did I say “two”? Oh, there might be three or more. Any natural number ℕ of them, really.

Unless your server is set up in a rather peculiar way, the following commands will return different results:

$ sudo podman info --format '{{.Store.GraphRoot}}'
$      podman info --format '{{.Store.GraphRoot}}'

And what is this “GraphRoot” in the first place? It is where Podman places the files belonging to each OCI image’s downloaded layers and the copy-on-write changes¹ resulting from instantiating those images, plus any named volumes you create bound to those containers. There are other files belonging to a container not stored under the GraphRoot, primarily bind-mounted filesystems like the faux /dev plus anything you manually added via --volume flags, but that gets us off our topic here.

A more relevant question here is, “Why does removing the sudo change the result?”

The answer is, “There are at least two separate Podman installations on this system.”

You Keep Saying That…

When initially reading up on Podman, you often hear about how Podman is “rootless” and that this is better, but what does that really mean?

The most salient answer here is that the podman command never has any more privilege than the user who ran it. Indeed, unless you pass the --privileged option, Podman takes away capabilities from the user when creating and running containers, all in the name of increased system security. You have to go out of your way to get broader capabilities than Podman’s restricted default.

In addition to the --privileged flag, one of the ways to gain additional capabilities is to run podman with root privileges, typically as

$ sudo podman…

As with a regular user’s call to the program, this strips some of root’s stock capabilities away in the name of security.

The thing is, calls like the above operate on a different “graphRoot” than for a normal user, as shown by the two commands I led off with in this article. If you have multiple regular users on that system, each of them will have their own graphRoots as well, each independent from the others.

What does this mean in practice? Although these two commands:

$ sudo podman run --rm -it alpine uname -a
$      podman run --rm -it alpine uname -a

…will print the same results because they’re run on the same host machine, they result in two separate pulls of the alpine:latest image, one stored in each of the graphRoots you discovered above. Moreover, the two instantiated containers live under those same graphRoots, one each.

This Is Feeling Like a Difference Without a Distinction…

Okay, try this on for size:

$ systemctl --user start podman
$ podman info --format '{{.Host.RemoteSocket.Path}}'

On a typical Linux server, that will return /run/user/1000/podman/podman.sock.²

But now do it as root:

$ sudo systemctl start podman
$ sudo podman info --format '{{.Host.RemoteSocket.Path}}'

You should get back /run/podman/podman.sock.

What we have just learned is that there are not only two — or potentially more! — independent Podman setups on this machine, but also two (or more) potential locations for the Podman API socket.

But Why?

Security, is why.

Contrast a default installation of Docker, which has just one of everything, all gated by a single containerd instance.³ One benefit of this is that it only had to pull alpine:latest once in the above example, but if you use their rootless mode for the second one, you end up with two separate containers, same as with Podman.

The primary distinction is that Podman is rootless by default, not by special configuration after the fact.⁴ While it is technically true that the running docker command instance never has any more privilege than the user running it, exactly as with podman, there's an important distinction: it does its work by producing and sending one or more REST API calls to containerd, which runs as root by default. If you can trick containerd into offering your user more capabilities than it ought to have, you've got a serious security vulnerability on your hands. Podman avoids this by not having a duplication of the privilege separation logic; security is left up to the underlying Linux kernel, as is proper. There isn’t a parallel system to break, no separate way for Podman to fail here. The only way to break the security surrounding all this is for the Linux kernel to fail.

This, needless to say, is extremely unlikely.

And that’s reason #2362 why Podman rocks.

License

This work is © 2025 by Warren Young and is licensed under CC BY-NC-SA 4.0

---

1. ^{^} How that occurs varies based on the storage driver. It might be overlayfs on top of ext4, which provides the latter with copy-on-write semantics, but it might also be btrfs which has its own CoW features and thus does not need any external help.
2. ^{^} The actual result may vary, especially in regards to the user ID value.
3. ^{^} In modern Docker setups, that is. In older ones, it was dockerd.
4. ^{^} Indeed, Docker’s rootless mode was introduced suspiciously shortly after Podman came on the scene. Coincidence? Not a chance.