james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 16770] - JAMES silently consumes java.lang.Error thrown by Maillet.service()
Date Tue, 04 Feb 2003 23:55:58 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16770>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16770

JAMES silently consumes java.lang.Error thrown by Maillet.service()





------- Additional Comments From raz+ncnpur.bet@raz.cx  2003-02-04 23:55 -------
Ah, superb timing.

You are right of course about the inaccuracy in my description, in all cases by
"JAMES" I meant "JAMES or one of the components upon  which it depends". I have
not yet looked deeply enough to make sense of what Excalibur is or does. (I'll
do so later.)

Given that it is Excalibur's WorkerThread that is silently consuming
java.lang.Error, then it might be reasonable to report the bug there (I don't
yet know enough to do this). Given that inserting a workaround into JAMES gets
JAMES clear of this bug, then I'm all for it of course.

At the risk of teaching you to suck eggs, I'll point out that, if you are going
to catch java.lang.Error, then a not-unreasonable response is System.exit().
This is because java.lang.Error and its decendants are generally used to signify
problems that represent a breach of the Java type system (e.g. out of memory,
classes missing, signatures altered incompatibly, etc.), in roughly the same
sense that a kernel panic does in an operating system. That Java allows you a
chance to clean up (by throwing an Error instead of aborting immediately) is a
deliberate feature, however using it to keep a broken type system running
indefinitely may introduce further problems. Most seriously, if a type system
breach leaves a SecurityManager in an inconsistent state (e.g. out of memory
leading to failed allocation of an object during the updating of a linked list
of credentials), then by catching Error and not aborting the JVM, you've
provided a vulnerability through which an adversary may breach access control,
confidentiality or integrity constraints.

Better to reduce availability and allow an adversary to bring about a denial of
service (by tickling a bug which aborts the JVM) than to open a potentially
serious hole. IMHO.

{{ Lecture ends :-) }}

---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org


Mime
View raw message