[SCM] Samba Shared Repository - branch master updated - b881d2ee78f685aea7ae8b67b3e0fb3c4f5205ed

Derrell Lipman derrell.lipman at unwireduniverse.com
Mon Oct 27 16:17:11 GMT 2008


On Mon, Oct 27, 2008 at 10:58 AM, Michael Adam <ma at sernet.de> wrote:


> > Michael, although this should help in the majority of cases, it looks
> like
> > it still leaves a race condition where you write the single byte, the
> peer
> > reads that byte so the socket is no longer in a readable state, you then
> > close the socket, and the original problem occurs.  I wonder if there is
> > some ioctl you can issue here that will force the peer into readable
> state
> > upon close...???
>
> In principle, I agree that this might introduce a race, but in
> practice the scenario is as follows:
>
> 1. Winbind only closes the socket for an inactive connection
>   (this is called from remove_idle_client() or on finished
>   connections).
>
>   This means that the client (smbd in our case) expects the
>   socket to be readable and winbindd to be waiting for the next
>   command on the pipe.
>
> 2. On the client end, in nsswitch/wb_common.c:winbind_write_sock(),
>   there is already the corresponding catch that will close the
>   socket, when it detects (by calling select) that read() would not
>   block on the socket (starting in line 387 in nsswitch/wb_common.c).
>
> Does this reduce your concerns?


Ok, so you're saying that an inactive connection is being closed, but that
would imply that the code in winbind_write_sock() isn't being called (by
that inactive client).  But there's someplace that wasn't previously getting
unblocked that your write of one byte causes to be unblocked.  It's *there*
that I see the potential race condition.

If you're convinced that your fix is "complete" (i.e. it doesn't allow for
the single character to be eaten prior to the close, leaving the client in
the same never-becomes-readable condition from before the fix), you don't
need to convince me.  I don't know this code.  I just brought this up as a
potential issue.

Cheers,

Derrell


More information about the samba-cvs mailing list