[Openvas-devel] [Openvas-commits] r1103-trunk/openvas-libnasl/nasl
bchandra at secpod.com
Wed Aug 6 17:26:09 CEST 2008
From: openvas-devel-bounces at wald.intevation.org
[mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Bernhard
Sent: Wednesday, August 06, 2008 7:36 PM
To: openvas-devel at wald.intevation.org
Subject: Re: [Openvas-devel] [Openvas-commits]
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
> 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.
More information about the Openvas-devel