* aCaB wrote: > The main reason the code is different is due to the fact that OnXXX > executes a script (with some params) via the shell and VirusEvent does > the same but additionally expands %v to the virus name. >
One of the OnXXX events does that too. Additionally VirusEvent exports some data to the environment. shell or no shell isn't important. environment variables or none isn't important. ARGV or no ARGV isn't important. What is important is deciding how to "consistently" do the common task. And the common task is "call an outside program". Once that is done, we can figure out the three "unimportant" options list above. > With the milter I had to face a few more issues. > On one hand I decided to drop mail notifications, which suddently made > VirusAction the most immediate and obvious work around. And I appreciate it. :-) > On the other hand, everything in the milter is arbitrary, unsanitized > and potentially nasty. > I conisdered that, for some reason, quite a few OS's/distros run the > milter as root and that the old milter had security issues related to > insufficient validation[1], and the decision was not to rely on the > shell for executing the external scripts. Ah, a very good idea. Which brings us to Item 1. shell or no shell. With the loss of the shell, we lose some flexibility in what we can call. However I feel that it is a good trade off, considering the security gained. I wouldn't complain if all the external events where done in the same way. More security just by deciding how to "consistently" do the common task. So I see where you are coming from. Item 2. environment variables or none. Here is where I am coming from. CLUES All events going to the same script. Regardless of which program calls CLUES it would be nice to have common stuff in the same place. CLUES was what bug 1754 was about. I wanted a Common Event Execution Environment before I built it. I needed VirusAction before I built it. So What do I have? I Have five Events to handle. Two are easy, they don't have anything to tell me. One will put everything in ARGV Two "might" put something in ARGV, and one of those will put data into the environment. What I'd like? If I had at least the event names exported to the environment, the presence or absence of a shell wouldn't be an issue. ( no need for vawrap ) If I had some of what I wanted in 1754, I could think a few more features to add to CLUES. If I had in the VirusAction environment what I have in VirusEcent environment. VirusAction would need one less ARGV and VirusEvent wouldn't need %v, actually it already doesn't. If you wanted to keep them thats fine, but you could lose them ( two incompatible ways of passing the same information ) without the loss of functionality. More functionality, and potentially less code complexity, just by deciding how to "consistently" do the common task. Item 3. ARGV or no ARGV. With Items 1 and 2 decided, this is just a question of, "Does the event have more to say than the Common Execution Environment allows" If so just put it on the command line args, or if appropriate go back to Item 2 and adjust the Environment. More clarity just by deciding how to "consistently" do the common task. In Conclusion I can think of at least three more CLmaAV events that it would be nice to be notified on. However, I feel that it is important to decide how to do one common task before covering new ground. Final opinion about how to do the common task. Use execle to call the script directly, and hand it a common Environment. Do this for all external events. -- Sincerely, Nathan Gibbs Systems Administrator Christ Media http://www.cmpublishers.com
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
