lxd does not run your containers -- it uses lxc to do so, and yes, lxc supports user namespaces (this is how you get rootless containers). In the end all these tools get here by doing the same thing, they do uid/gid mapping[0 - search "UID MAPPINGS"][1] and some filesystem module (whether kernel or user space) support. Why that is necessary is basically due to how the kernel works, and how containers work in general which I will leave as an exercise in the reader (hint: a "container" struct does not exist in the linux kernel, containers are a combination of processes and isolation via namespaces and cgroups and other kernel features).

What lxd provides is a layer above lxc to coordinate the containers being run (by lxc) and relevant resources on the machines you want.

[0]: https://linuxcontainers.org/lxc/manpages/man5/lxc.container....

[1]: http://docs.podman.io/en/latest/markdown/podman-create.1.htm...

From your link:

"The remote API uses either TLS client certificates or Candid based authentication. Canonical RBAC support can be used combined with Candid based authentication to limit what an API client may do on LXD"

So it's not configured out of the box, but possible.

In that sense docker is also "rootless". Won't be surprising if Canonical does not understand the words they use.

EDIT: actually I find no claims that LXD/LXC supports rootless containers, I think the person claiming it does just don't understand it, would like to see a citation for it.

That's because by default ALL containers in LXD are unprivileged. They use the term unprivileged because the term rootless wasn't around that far back ;)

LXD uses various mechanisms to map the uid-in-container to a uid-on-host. So root-in-container is not root on host. There are a lot of details to work through to make that work neatly, and there is still kernel work being done to map this nicely into the filesystem, but it works, and it's the default, and the FAQ recommends strongly not to grant real-root to your containers, for a good reason.

Great summary -- for anyone interested in the kernel side, there's a talk from 2019 called "A year of Container Kernel Work Past, Present, and Future of Container Kernel Features"[0] which goes into the timeline and future work being done. I'm not sure where it is today but it's a good watch.

[0]: https://www.youtube.com/watch?v=TnArHYRYT3U