On Tue, Aug 26, 2025 at 03:02:13PM +0000, Pasha Tatashin wrote: > I'm trying to understand the drawbacks of the PID-based approach. > Could you elaborate on why passing a PID in the RESTORE_FD ioctl is > not a good idea? It will be a major invasive change all over the place in the kernel to change things that assume current to do something else. We should try to avoid this. > In this flow, the client isn't providing an arbitrary PID; the trusted > luod agent is providing the PID of a process it has an active > connection with. PIDs are wobbly thing, you can never really trust them unless they are in a pidfd. > The idea was to let luod handle the session/security story, and the > kernel handle the core preservation mechanism. Adding sessions to the > kernel, delegates the management and part of the security model into > the kernel. I am not sure if it is necessary, what can be cleanly > managed in userspace should stay in userspace. session fds were an update imagined to allow the kernel to partition things the session FD it self could be shared with other processes. I think in the calls the idea was it was reasonable to start without sessions fds at all, but in this case we shouldn't be mucking with pids or current. Since it seems that is important it should be addressed by issuing the restore ioctl inside the correct process context, that is a much easier thing to delegate to the kernel than trying to deal with spoofing current/etc. Jason
