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

Chandrashekhar B bchandra at secpod.com
Wed Aug 6 17:26:09 CEST 2008


-----Original Message-----
From: openvas-devel-bounces at wald.intevation.org
[mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Bernhard
Herzog
Sent: Wednesday, August 06, 2008 7:36 PM
To: openvas-devel at wald.intevation.org
Subject: Re: [Openvas-devel] [Openvas-commits]
r1103-trunk/openvas-libnasl/nasl

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?

Yes, the rest of the code seems to just validate for NULL. I always get 4,
let me see if I can do some testing to figure who's eating up 3. 

> 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.

It always returns 4 for me in stand-alone mode. 

>   Bernhard




More information about the Openvas-devel mailing list