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