The first two are just kind of the nature of containers on linux, and applies to any container technology.
Podman does allow you to run it as a non-root user (with some limitations), that was in fact one of the biggest motivations for making podman. This wasn't possible at all in the early days of docker, it wasn't until linux introduced user namespaces, where the root user inside the namespace mapped to a non-root user id outside the namespace that non-root conatiners were possible.
And podman, unfortunately IMO, is also written in go.
Podman, by default, uses crun as the container runtime, which is written completely in C. Podman is basically just a frontend for managing running containers.
Not anymore, they switched to runc (but it can use any OCI compliant runtime)
Otherwise it’s basically the same and you can continue using your Dockerfiles and Docker Compose files.
Unless you’re doing something really fancy it’s basically a drop-in replacement.
Unfortunately, there’s an unconditional setsid during podman’s container setup, which as far as I could tell exists so that the container can be detachable.
(This was all so that I could have the same job management with Ctrl-Z, SIGSTOP, SIGTSTP, fg, and bg, regardless of whether the process I’m running starts up a container. The only way I’ve found to have that is by handling chroot/unshare myself.)
If not for the uncatchable SIGKILL/SIGSTOP, I'd say that any process that calls `setsid` is responsible for ensuring signal propagation across the pgid. But since those are uncatchable, I tend to shrug and figure that I'll avoid setsid wherever possible.
There was a proposal at one point that would have had `unshare(NEW_CGROUP)` place the process into a child cgroup, rather than merely changing the name of the current cgroup. This would have meant that cgroups could actually be used for nested process management. Unfortunately, there's no guarantee that a process can ever make nested cgroups it wouldn't be sound for all supported resource constraints, so that proposal never went in. But that would have been nice to actually have nestable job management.
How?! After a process calls setsid(2), it becomes a leader of a new process group so it stops receiving signals from its former process group!
> But that would have been nice to actually have nestable job management.
Yes, it would be. Just imagine: a simple, straightforward way to group a bunch of processes (and their potential children, inescapably), signal them all at once, wait for them all at once, etc. Instead, we at best ended up with docker compose and k8s. And they kinda do solve that problem, no question about that but it's just so incredibly heavyweight...
By limiting its usage to the period between fork and exec, so that the process calling setsid knows that the parent process is propagating signals to it.
So, my phrasing was inaccurate to the point of being entirely incorrect. I should have said that any process that calls `setsid` is responsible for ensuring that signals are being propagated. (And saved! Definitely didn't make a mistake on the internet and then play it like I was right all along.)
Well, again, the process that calls setsid(2) ceases to receive the signals from its previous process group, so there is nothing for it to propagate. The only way this propagation can work is with cooperation from the parent process of the setsid-calling process: it will need to manually pass the group-wide signals to its setsid-calling child — which it can't reliably do for two obvious reasons.
> By limiting its usage to the period between fork and exec, so that the process calling setsid knows that the parent process is propagating signals to it.
Wait. Are you implying a scheme where the process A, that wants to do setsid(2), forks itself, and it's this child process B that does setsid(2) and all future actual work, while process A merely lives in a "while(1) { sig = sigwait(); signal(pidB, sig); }" loop forever? This almost works but doesn't survive SIGSTOP/SIGCONT/etc. and, of course, you can't propagate SIGKILL. And SIGKILL-propagation is arguably one of the main attraction of the process groups — you send SIGKILL to the process group (or a container, for that matter), and all of it dies with no further work on your part.
:D
A lot of the more important syscalls involved do require root.
Podman also has a fully rootless mode which can work for many uses: https://github.com/podman-container-tools/podman/blob/main/d...
Or a setuid binary
I don't know why you're so shocked by this? This is all very basic use of the OCI spec.
> 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
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