D 2025-06-23T21:16:33.097
L There\sAre\sTwo\sPodman\sInstallations
N text/x-markdown
P 6427e3d71159f969ccd70e2c7281d45c4b1744c992f9d0e3cfbd6d78be273202
U tangent
W 6291
## Say _What_ Now?
Did I say “two”? Oh, there might be three or more. Any [natural number](https://en.wikipedia.org/wiki/Natural_number) ℕ of them, really.
Unless your server is set up in a rather peculiar way, the following commands will return different results:
``` shell
$ 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(^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.) 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
``` shell
$ 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:
``` shell
$ 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:
``` shell
$ systemctl --user start podman
$ podman info --format '{{.Host.RemoteSocket.Path}}'
```
On a typical Linux server, that will return `/run/user/1000/podman/podman.sock`.(^The actual result may vary, especially in regards to the user ID value.)
But now do it as root:
``` shell
$ 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.(^In modern Docker setups, that is. In older ones, it was `dockerd`.) 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](https://docs.docker.com/engine/security/rootless/) 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.(^Indeed, Docker’s rootless mode was introduced _suspiciously_ shortly after Podman came on the scene. _Coincidence?_ Not a chance.) 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.
## <a id="license"></a>License
This work is © 2025 by Warren Young and is licensed under <a href="http://creativecommons.org/licenses/by-nc-sa/4.0/" target="_blank" rel="license noopener noreferrer">CC BY-NC-SA 4.0<img style="height:22px!important;margin-left:3px;vertical-align:text-bottom;" src="https://mirrors.creativecommons.org/presskit/icons/cc.svg?ref=chooser-v1"><img style="height:22px!important;margin-left:3px;vertical-align:text-bottom;" src="https://mirrors.creativecommons.org/presskit/icons/by.svg?ref=chooser-v1"><img style="height:22px!important;margin-left:3px;vertical-align:text-bottom;" src="https://mirrors.creativecommons.org/presskit/icons/nc.svg?ref=chooser-v1"><img style="height:22px!important;margin-left:3px;vertical-align:text-bottom;" src="https://mirrors.creativecommons.org/presskit/icons/sa.svg?ref=chooser-v1"></a>
<div style="height: 50em" id="this-space-intentionally-left-blank"></div>
Z a07ebf07f4037904bc4d105e43341ad9