Jan-Oliver Wagner wrote: > Hi, > > I looked at the code/concept we inherited from Nessus > regarding services handling (modules openvas-libraries/misc/services*). > > To me it looks like multiple broken concept. > > What I understand so far is: > > * /etc/services is used through the standard glibc API > * in openvas-server there is a openvas-services file > that may work as an alternative to the system wide > file. > * nmap knows even more about services. > > What's broken? > (I might be wrong here, so please comment, discuss) > > * My guess is that the nessus authors believed > the system wide file is not always enough up-to-date. > With their own file they unlink dependency to OS version > and introduce dependency link to Scanner version.
As far as I can see, the daemon does a fallback to glibc linked to /etc/services - it's just that first dibs are given to the daemon's version of the services file, and only if the name cannot be found does it fall back to glibc use of /etc/services. > This leads to the problem that in several cases, people > may use even older services data because they use > an old scanner on a new OS. > They might also have had the intention to make > the scanner run on Windows eventually. > > * It is questionalbel whether it makes sense at all > to maintain services database on out own at all. > In case we would do it, the only sensible way > is to distribute it over the feed so it is always > uptodate. > > * What we might really want is to share effords > with the nmap people. Distributuing the newes > data via the feed remains still an option here. > > What to do? > > IMHO, we should drop the whole services code > stuff and use the glibc API using a thin layer > that allows us to go for a nmap database > distributed via feed. > > You opinions welcome! I'm not sure I see too much wrong with the fall-back approach currently in use. That being said, the services file I think could benefit from being distributed with the feed to have it be up to date, so moving this file from the $CONF directory to the script feed direction seems to make good sense. Thomas _______________________________________________ Openvas-devel mailing list Openvas-devel@wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-devel
