inetd bug
Cathey, Jim
jcathey at ciena.com
Wed Nov 5 18:51:21 UTC 2008
In which case that should at least be in the
commentary:
// Assumes that FD_MARGIN is >0, to avoid maxsock==-1 problems.
if ((rlim_t)(maxsock+FD_MARGIN) > rlim_ofile_cur)
Possibly even an assert or a compile-time #if #error construct?
-- Jim
-----Original Message-----
From: walter harms [mailto:wharms at bfs.de]
Sent: Wednesday, November 05, 2008 10:33 AM
To: Cathey, Jim
Cc: Denys Vlasenko; busybox at busybox.net
Subject: Re: inetd bug
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
>
>
>
More information about the busybox
mailing list