stat(2) triggers on-demand virus scan

[Chris Taylor]

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/