X-Spam-Check-By: sourceware.org Message-ID: <43C9758B.3090708@equate.dyndns.org> Date: Sat, 14 Jan 2006 22:04:59 +0000 From: Chris Taylor Reply-To: cygwin AT cygwin DOT com User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) MIME-Version: 1.0 To: Brett Serkez CC: cygwin AT cygwin DOT com Subject: Re: stat(2) triggers on-demand virus scan References: <1137270917 DOT 8322 DOT 251859045 AT webmail DOT messagingengine DOT com> <20060114203858 DOT GB9302 AT trixie DOT casa DOT cgf DOT cx> <1137273523 DOT 12135 DOT 251862141 AT webmail DOT messagingengine DOT com> In-Reply-To: <1137273523.12135.251862141@webmail.messagingengine.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Brett Serkez wrote: >>On Sat, Jan 14, 2006 at 03:35:17PM -0500, Brett Serkez wrote: >> >>>I'm still researching, I was going to respond this is posting at a >>>later time with more insight, but before things get out-of-hand, I >>>wanted to jump in. I suppose I'm still hopeful that we can zero in >>>on what precisely is causing the on-demand scanners to consume so >>>much CPU. Since Windows programs don't trigger the same level of >>>response (or atleast they don't appear to) their must be some change >>>that can be made. >> >>I just wanted to make it clear that we aren't going to be making any >>special concessions to a product like a virus scanner which cause >>perfectly acceptable code to misbehave. If that is the case then it >>is a situation for the virus scanner to work out. It's not a >>requirement that cygwin work around things like this. > > > Well, that is a pretty strong statement, I'd expect from a for-profit > company run by corporate management. ZoneLabs offical stance is that > they don't support emulated environments. Humm... So if neither are > willing to change, then what? I don't know Symantec's or McAfee's > offical stance. They're likely to be the same. While cgf's statement could be interpreted in the same vein, you have to look at it from other points of view as well.. See comments below. > > As far as coding being 'perfectly acceptable', that is a matter of > point-of- > view. If it causes such behavior, is it acceptable? Cygwin is not what is at fault here - it is the way many on-demand virus scanners interact with the OS, the OS itself, and how ZA hooks in to the net-code, that cause these issues. Cygwin code is correct according to ms sdk and available documentation - it uses the correct and most accurate methods to implement POSIX functionality and *nix integration that are available and known. (Note that this statement is not entirely accurate, or the next would not be at all) Obviously, as time goes on, improvements can be made, but that is the nature of software development. > > While I respect the purist point of view, one I've held over the years, > seems that we need to be practical sometimes. Are you saying that if > the problem could be isolated, and reasonable changes proposed, you > wouldn't make/allow them? Do we want IT administrators to utilize > Cygwin to integrate with the Linux/UNIX environment? If this means not > being able to effectively use Cygwin if they are also required to run > ZoneAlarm, Norton, McAfee, what choice do you think they'll make, or > more precisely, their management will make on their behalf? If a change could be made to correct the issues that cygwin has on systems that have these products 'inflicted' upon them [1], without causing any reduction in performance in other circumstances, making the code vastly more complex, or requiring additional resources or user intervention, then I suspect it would become a PTC issue. [1] - I choose the word inflicted deliberately - in my experience, norton and mcafee are very bad AV products, and only getting worse as they forcibly integrate other products into them. They frequently miss genuine threats and generate false positives, and fail thorough tests on a regular basis. As a rule, IT admins have sufficient say that they can change company policy in regards to AV and firewall software. Indeed, in a corporate environment, it is *extremely* unusual to come across software firewalls being in use, beyond possibly an implementation of IPTables filtering traffic between the network and the internet, and between remote sites. Usually, there will be hardware firewalls, such as FW1, Cisco PIX, or Nokia's firewall product, whose name I forget. If you name a circumstance where office-based machines require a software firewall, a strong argument can be made as to how and why that network has not been properly secured. In my opinion, this also applies to on-access virus scanners. Feel free to ask me why in a direct email, that would be OT for this list. > > Since we ultimately don't know the root cause, this discussion is > premature, however if the group isn't going to be open to changes, there > is no point trying to find them, time would be better spent finding > alternates. That would be ashame as I think Cygwin is the most > progessive tool available for IT and development work. Certainly for > those attempting to bridge the Linux/UNIX - Windows environment. > In all honest, you have three options that can be used within windows. Cygwin, MinGW, and SFU. Of those, MinGW is not really all that well suited to these circumstances, and SFU does not have nearly the range of capabilities that Cygwin has. While cgf is on record as saying he does not want to work around issues with other software, if evidence were to emerge to show cygwin could use another method without any detriment, I imagine it would be considered. However, specifically with regards to on-access AV, I don't believe there will be another way to deal with this, because of the way on-access scanning functions.. Certainly, this will not be true across the board, but I suspect that these AV programs are intercepting direct calls and running them through themselves, giving them the chance to scan the data as it is read. Not only does this slow everything down, it also results in CPU usage. If this is indeed the case, then the on-access scanners are not performing their configured task - they are supposed to monitor specific file types, as defined in their setup. If they intercept all direct accesses and scan the files, then they are ignoring what they have been told to deal with. That said, even when configured to only deal with specific files, there is a good chance that everything would still go through them, so that they can first determine filetype. This will increase latency and cpu usage on it's own. My response to those using on-access scanners on a corporate network is don't. Turn them off, disable floppy and usb stick usage, schedule regular scans of your server and machines out of working hours, and scan all incoming and outgoing email. If an outgoing email is infected, make sure that the admins are notified who sent it. This, along with decent filtering of the net, solves these problems. Chris -- Spinning complacently in the darkness, covered and blinded by a blanket of little lives, false security has lulled the madness of this world into a slumber. Wake up! An eye is upon you, staring straight down and keenly through, seeing all that you are and everything that you will never be. Yes, an eye is upon you, an eye ready to blink. So face forward, with arms wide open and mind reeling. Your future has arrived... Are you ready to go? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/