FreeBSD + samba 2.2.2 problems; semi-solution

[Mike Silbersack]

On Thu, 17 Jan 2002, Jeremy Allison wrote:

> On Thu, Jan 17, 2002 at 06:58:03PM +0000, Mike Silbersack wrote:
> >
> > In either case, have you looked at switching the blocking reads to use a
> > timeout instead?  That seems like it would be a good idea, even once this
> > bug is found and fixed.
>
> Hmmmmm. So the desired effect is - once the client has sent the
> length field, if no more data follows in, say, 60 seconds, then
> we terminate ?
>
> That would limit smbd's staying around with (what I must say
> are) COMPLETELY BROKEN CLIENTS !!!
>
> Sorry for shouting, but clients that do that sort of thing
> bug me :-).
>
> Jeremy.

Yes, that is what I'm proposing.  Certainly, such an occurance should be
rare.  Making such a change would just be a way to make sure that in the
case of something like this happening, samba will fail nicely.  If you
want to be really complete, you could make sure that the timeout error
message is included in the default error reporting level so that people
can see that the client is at fault.

Basically look at it like this:

If the client goes quiet, one of two things can happen:

1.  Samba uses a blocking read, and smbd sits there for a long while doing
nothing.  Sysadmin is forced to manually kill samba to release oplocks,
and becomes angered at samba.

2.  Samba selects on the socket, timing out after 60 seconds, releasing
oplocks, and printing an error message to the log.  Sysadmin hears of a
problem, checks the log, and sees that the client has done something silly
and samba has handled the problem for him.

While I'm on the subject, I think there's a bit of code in
read_socket_with_timeout which needs to be examined:

rns true on disk files */

  /* Set initial timeout */
  timeout.tv_sec = (time_t)(time_out / 1000);
  timeout.tv_usec = (long)(1000 * (time_out % 1000));

  for (nread=0; nread < mincnt; ) {
    FD_ZERO(&fds);
    FD_SET(fd,&fds);

    selrtn = sys_select_intr(fd+1,&fds,&timeout);

Linux will decrement timeout by however long it took to return, while
other OSes may not.  It would be safer to move the setting of
timeout.tv_sec and tv_usec inside the for loop so that OS-dependent timing
effects do not occur.  (For example, if a 10 second timeout was passed and
three packets came, one every 5 seconds, linux would return before the
third packet arrived due to a timeout; other oses would probably receive
all the packets, as they would use 10 seconds as the timeout each time.)

Mike "Silby" Silbersack