1. Client connects and resumes its session with luod. 2. Client requests to restore TOKEN_X. 3. luod verifies the client owns TOKEN_X for its session. 4. luod calls the RESTORE_FD ioctl, telling the kernel: "Please restore TOKEN_X and charge the resources to PID Y (which I just verified is on the other end of this socket)." 5. The kernel performs the action. 6. luod receives the new FD from the kernel and passes it back to the client over the socket. 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. 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. Thanks, Pasha > > Jason
