This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: stat(2) triggers on-demand virus scan


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]