Re: pluginload 'bug' fix, patch included

"Cory Marsh" <[email protected]>
Newsgroups gmane.comp.security.nessus.devel
Organization Idaho Power
Message-ID <1067975954.5752.47.camel@localhost>
Is there any additional information about this or has anyone else
encountered this?  The problem is easy to reproduce.  Simply do a cvs
import of your nessus plugin directory and restart nessusd.  The next
time you connect, you should see some strange plugin categories.  On my
FreeBSD systems, this is the only problem I encounter.  On my Redhat
Linux systems (RH 8 & RH 9), the nasl plugins are loaded as type nes and
handed to nes_plugin_launch, which creates a misleading fork() error in
the logs.  I am sure that the bug or "misbehavior" lies somewhere
outside of files_walk(), however I think that files_walk() should in
fact only be returning regular files.  As it currently stands calls to
files_walk() will return directories, sockets, pipes and other file
oddities which are most likely not valid nessus plugins (I suppose pipes
and sockets could have servers associated with them, feeding nasl code,
however this seems highly odd and I can't think of a good reason to
support this behavior).  

Perhaps the plugin loading code is requiring (assuming) that the file
has a file extension?  This is just speculation; however, as to why the
CVS directory is causing problems.  I think that requiring files_walk()
to only return standard files is good behavior. The function call is to
stat() not fstat(), so symbolic links should be uneffected.  Comments?

Regards,
Cory


On Tue, 2003-11-04 at 11:56, Renaud Deraison wrote:
> On Tue, Nov 04, 2003 at 11:47:06AM -0700, Cory Marsh wrote:
> > I have noticed "strange" plug-in errors occurring whenever I use CVS to
> > maintain my nessus plugins.  This includes mangling the script category
> > so that my windows plugins show up in the "sc" category and other
> > oddities.  This came to a head yesterday when a new system I setup
> > started receiving fork() errors in the log file for each executed
> > plugin.  This obviously yielded less than desirable results.  After
> > loading nessus in gdb and attaching to the offending processes, I added
> > some logging in pluginlaunch.c at line 515:
> 
> The weird thing is that nessusd should not attribute any function to
> "unknown" plugins - this is why .inc files are not loaded. 
> 
> So while I don't really understand why you are encountering this issue,
> I doubt your patch is actually the proper way to fix it, and it might
> become an inconvienience to some extent.
> 
> 
> 				-- Renaud
> 



[INFO] -- Access Manager:
This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law.  If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.  Thank you.   A2
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.