inetd bug

[walter harms]

Cathey, Jim schrieb:
> I don't think casting the rlim_t's to int
> is going to cause a problem here, given that
> their values are unlikely to approach overflow
> for even a 16-bit int.
> 
> Or, given an allowable maxsock of -1, one could
> re-code the affected comparisons to incorporate
> a +1 to get out of negative territory altogether:
> 
>       // +1 bias eliminates maxsock==-1 problems.
> 	if ((rlim_t)(maxsock+1) > (rlim_ofile_cur+1) - FD_MARGIN)


assuming that FD_MARGIN is >0 forever.

	if (  (rlim_t)(maxsock+FD_MARGIN) > rlim_ofile_cur )

this will work for 64bit and honors unsigned.








> -----Original Message-----
> From: busybox-bounces at busybox.net [mailto:busybox-bounces at busybox.net]
> On Behalf Of Cathey, Jim
> Sent: Wednesday, November 05, 2008 9:48 AM
> To: Denys Vlasenko; wharms at bfs.de
> Cc: busybox at busybox.net
> Subject: RE: inetd bug
> 
> On the face of it I think this fix is inadequate,
> given that "maxsock + 1" is used in the select().
> With no services, should select not have a 0 as the
> first argument, thus requiring maxsock to be -1 and
> not 0?  All the problems fell out of that value.
> 
> -- Jim
> 
> 
> 
> -----Original Message-----
> From: Denys Vlasenko [mailto:vda.linux at googlemail.com] 
> Sent: Wednesday, November 05, 2008 3:37 AM
> To: wharms at bfs.de
> Cc: Cathey, Jim; busybox at busybox.net
> Subject: Re: inetd bug
> 
>> Cathey, Jim schrieb:
>>> We've been using BB, and found that when we had an /etc/inetd.conf
>>> file with only one service in it, said service being commented in
>>> and out as it was enabled/disabled by the system (along with a HUP
>>> to inetd), that the lone service could not re-enable.  I tracked it
>>> down to a bug where the maxsock variable wasn't being used correctly.
> 
> Can you explain where exactly that failed? Form what I can see,
> the only erroneous place is this one (fix is shown too):
> 
>  static void recalculate_maxsock(void)
>  {
>         int fd = 0;
> +       maxsock = 0;
>         while (fd <= prev_maxsock) {
>                 if (FD_ISSET(fd, &allsock))
>                         maxsock = fd;
> 
> Basically, if there are no services at all, maxsock was not updated
> and stayed -1, the rest of code was not expecting that can ever happen
> after recalculate_maxsock().
> 
> Am I right in my analysis or are there other places where code is wrong?
> IOW, does the above fix work for you?
> --
> vda
> 
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox
> 
> 
>