Docker Is Weird

Re:Docker Is Weird by 80fj0348i on Saturday October 24, 2026 @12:18AM (#50218337)

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.

[ Parent | on HN ]

Re:Docker Is Weird by asveikau on Saturday October 24, 2026 @12:39PM (#50222907)

It's because from a kernel perspective this part literally needs root:

> just trying to execute the command within the child container's filesystem

There is no such thing as changing your root filesystem or your uid from an an unprivileged process. There is no "just do it in user mode" either.

So they must have a root process somewhere doing it for you.

I just started googling, apparently for podman the setuid root binary is newuidmap

[ Parent | on HN ]

Re:Docker Is Weird by LegionMammal978 on Saturday October 24, 2026 @12:48PM (#50222981)

Linux by default allows unprivileged processes to create user namespaces, without needing root [0] ("Since Linux 3.8, unprivileged processes can create user namespaces, and the other types of namespaces can be created with just the CAP_SYS_ADMIN capability in the caller's user namespace."), and then create mounts, adjust the filesystem root, etc. within those unprivileged namespaces.

It's only in recent years that it's become trendy for distros to disable unprivileged user namespaces in the name of reducing kernel attack surface. So while a privileged daemon is needed for those distros, there is no such inherent restirction on the kernel level.

[0] https://man7.org/linux/man-pages/man7/user_namespaces.7.html

[ Parent | on HN ]