I think the only thing in the "weird things" list that don't necessarily apply to another container system on linux would be the go-specific issues.

▲

80fj0348i a day ago | parent [-]

Most of the other container runtimes don't require root for many of the use cases in which Docker does.

▲

asveikau 14 hours ago | parent [-]

Care to give some examples?

A lot of the more important syscalls involved do require root.

▲

80fj0348i 11 hours ago | parent [-]

I've used crun without root for a lot of practical use cases, if you are only doing limited use of the network and are careful with volume mounts it works pretty well.

Podman also has a fully rootless mode which can work for many uses: https://github.com/podman-container-tools/podman/blob/main/d...

▲

asveikau 10 hours ago | parent [-]

I would guess that they do that by having a root daemon which authenticates requests from a unix domain socket, possibly using SO_PEERCRED.

Or a setuid binary

▲

80fj0348i 4 hours ago | parent [-]

They mostly work by just implementing the functionality in userspace instead of using syscalls. No daemon needed.

▲

asveikau 3 hours ago | parent [-]

That cannot be true. You need to tell the kernel about the namespaces, cgroups, and the new root. Otherwise it's not a container, and there is no reason or mechanism for a child proc to respect it. And if you let any old unprivileged process do this, you open up security problems.

	▲	80fj0348i an hour ago \| parent [-]
		I've done this for practical use cases, like running a container inside another container that didn't have root privileges. It works fine for that use case. I'm not worried about restricting access of the process because it's already within a larger sandbox, I'm usually just trying to execute the command within the child container's filesystem (e.g. some vendor/partner software they ship as a container image). I don't know why you're so shocked by this? This is all very basic use of the OCI spec.