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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Openvas-devel mailing list [email protected] http://lists.wald.intevation.org/mailman/listinfo/openvas-devel
