Mail Archives: cygwin/2006/01/14/17:05:33
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/
- Raw text -