On Tue, 14 Feb 2023 12:51:22 +0100 Michal Privoznik <mprivozn(a)redhat.com> wrote:When passt starts it tries to do some security measures to restrict itself. For instance, it creates its own namespaces, umounts basically everything, drops capabilities, forks off to further restrict itself (the child is where all interesting work takes place now). This is sound, except it's causing two problems: 1) the PID file FD, which we leak into the passt process, gets closed (and thus our virPidFile*() helpers see unlocked PID file, which makes them think the process is gone),I didn't realise this was the case, but giving passt write (unless I'm missing something) access to a file created by libvirtd doesn't look desirable to me.2) the PID file no longer reflects true PID of the process. Worse, the child calls setsid() so we can't even kill the whole process group. I mean, we can but it won't be any good. Fortunately, passt has '--foreground' argument, which causes it to undergo the same security measures but without forking off the child.They're not the same -- unfortunately they can't be, because, on Linux, you can't change the PID of an existing process, so there's no way to enter a new PID namespace without clone(). If passt remains in the same PID namespace, it's still able to see PIDs of other processes, which is not desirable from a security perspective. Again from a security perspective, this is probably a small impact, so I guess it's fine if there's no other way around it. But I see a lot of ways around it... -- Stefano