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.