[Openvas-devel] [Openvas-commits] r1103 -trunk/openvas-libnasl/nasl

Bernhard Herzog bh at intevation.de
Wed Aug 6 16:05:56 CEST 2008


On 06.08.2008, Chandrashekhar B wrote:
> When we call open_sock_udp(port), fd value returned is 4 and upwards on
> multiple calls. So, when nasl_close_socket() is called, it justs returns
> without closing the local port bound to the socket, when the fd value is 4.

Well, it was more or less obvious that you ran into a situation where the sock 
value was 4.  However, what I'd like to know is deeper, and only accidentally 
related to your commit.  The commit modifies code which seems somewhat 
suspicious.  My questions are more about that code in general.

nasl_close_socket seems to be the only place in nasl/nasl_socket.c where the 
value of the socket filedescriptor is checked in this way.  That in itself is 
strange.  Why only there?  Also, why can't the socket fd be less than 4?  I 
could sort of understand 3 (0, 1, 2 are already taken by the standard 
streams) but 4? Does the openvas server and/or the NASL interpreter guarantee 
that at least one other file is open?

My guess is that the check is there to prevent NASL scripts from closing file 
descriptors needed by openvas/NASL which includes the ones it uses for 
accessing the knowledgebase.  If that's the case, then the test has too much 
knowledge of the circumstances under which the NASL interpreter runs.  It 
should be moved to a separate function whose behavior can be influenced by 
the program embedding the NASL interpreter.  Other functions should probably 
also check the descriptors.

I also wonder whether the original code (disallowing any file descriptor <= 4) 
actually was correct and the real defect is that open_sock_udp actually 
returned 4.  Under which circumstances does it actually do that?  In my brief 
tests with the stand-alone nasl interpreter the smallest number it returned 
was 5.

   Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.wald.intevation.org/pipermail/openvas-devel/attachments/20080806/cd940aa9/attachment.pgp


More information about the Openvas-devel mailing list