Re: Reauthentication implementation flaw due to EINTR

[Da Zheng]

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