Hi, On 09-12-22 上午3:43, Samuel Thibault wrote: > Hello, > > I had been noticing odd issues with sudo when it calls setresuid & > such, it took me some time to understand that there was a flaw in the > reauthentication implementation: > > sudo calls setresuid(), which calls setauth(), which (for each FD & > such) allocates a rendez-vous port, calls io_reauthenticate() (RPC > in the underlying FS which calls the auth_server_authenticate() > RPC) and calls the auth_user_authenticate() RPC. These last two > RPCs end up in auth, which uses the rendez-vous port passed along > to make the match. Whichever arrives first leaves information and a > condition variable for the other ; when the latter arrives, it fills its > information and wakes the former. > > The issue is that currently, once the user part gets its passthrough > port from the server part, it returns immediately, and setauth() drops > the rendez-vous port, which actually interrupts the server RPCs because > the rendez-vous sender right becomes dead. Quite often scheduling makes > it so that the user is not so fast and the server has time to finish its > duties, but due to the high usage of setresuid in sudo, one every few > tens of sudo calls fail. > > The fix I'll use at least on the Debian buildds for now is to make the > auth_user_authenticate() RPC always wait for auth_server_authenticate() > to have called auth_server_authenticate_reply() before returning. I've > been running that in a tight loop the whole afternoon with no issue, so > at least it seems to work much better. However, I'd prefer to make sure > that it works _always_ :) I wonder if this bug causes my modified subhurd to hang in the place where `login` is executed. In the modified subhurd, all RPCs are forwarded to `boot`. Maybe it magnifies the problem here.
Samuel, could you send me your fix? I want to see if your patch can make it work. Thanks, Zheng Da
