You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "Peter Jones (JIRA)" <ji...@apache.org> on 2007/07/27 23:08:53 UTC
[jira] Created: (RIVER-138) (mux) low-level cause exceptions thrown
to multiple parties that don't trust eac
(mux) low-level cause exceptions thrown to multiple parties that don't trust eac
--------------------------------------------------------------------------------
Key: RIVER-138
URL: https://issues.apache.org/jira/browse/RIVER-138
Project: River
Issue Type: Bug
Affects Versions: jtsk_2.0
Reporter: Peter Jones
Priority: Minor
Bugtraq ID [4858644|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4858644]
When an entire mux connection goes down because of an exception, that exception is recorded, and that recorded exception is later used as the lower-level "cause" of {{IOException}}s that get thrown from I/O operations on the connection-- such as reading or writing on individual sessions' streams. This occurrence is made much more likely with the fix for [4856965|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4856965], although it actually could happen before that fix too (I just realized). The same connection could be being used by multiple parties that do not trust each other, and thus it may be unwise to give them access to the same exception, given that exceptions are generally mutable-- especially to the extent that we think that one might make program logic decisions based on any mutable state in a lower-level cause exception.
The stack trace of any exception is completely mutable, but that seems like a lesser concern. {{RemoteException}}, {{ActivataionException}}, and certain serialization-related {{IOException}} subclasses have public fields, although they seem unlikely to be thrown in this particular situation. {{org.ietf.jgss.GSSException}} has a public method to set the minor error code and message (but not the major...). Another more general issue is that any exception that hasn't had its cause set can be set by anyone with a reference to it with any arbitrary cause.
Despite the desire to provide as much possibly helpful debugging information as possilbe in exception traces, it might be prudent to try to prevent this sharing of access to cause exception across multiple users.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (RIVER-138) (mux) low-level cause exceptions thrown
to multiple parties that don't trust eac
Posted by "Peter Jones (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Jones updated RIVER-138:
------------------------------
Component/s: net_jini_jeri
Description:
Bugtraq ID [4858644|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4858644]
When an entire mux connection goes down because of an exception, that exception is recorded, and that recorded exception is later used as the lower-level "cause" of {{IOExceptions}} that get thrown from I/O operations on the connection-- such as reading or writing on individual sessions' streams. This occurrence is made much more likely with the fix for [4856965|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4856965], although it actually could happen before that fix too (I just realized). The same connection could be being used by multiple parties that do not trust each other, and thus it may be unwise to give them access to the same exception, given that exceptions are generally mutable-- especially to the extent that we think that one might make program logic decisions based on any mutable state in a lower-level cause exception.
The stack trace of any exception is completely mutable, but that seems like a lesser concern. {{RemoteException}}, {{ActivataionException}}, and certain serialization-related {{IOException}} subclasses have public fields, although they seem unlikely to be thrown in this particular situation. {{org.ietf.jgss.GSSException}} has a public method to set the minor error code and message (but not the major...). Another more general issue is that any exception that hasn't had its cause set can be set by anyone with a reference to it with any arbitrary cause.
Despite the desire to provide as much possibly helpful debugging information as possilbe in exception traces, it might be prudent to try to prevent this sharing of access to cause exception across multiple users.
was:
Bugtraq ID [4858644|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4858644]
When an entire mux connection goes down because of an exception, that exception is recorded, and that recorded exception is later used as the lower-level "cause" of {{IOException}}s that get thrown from I/O operations on the connection-- such as reading or writing on individual sessions' streams. This occurrence is made much more likely with the fix for [4856965|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4856965], although it actually could happen before that fix too (I just realized). The same connection could be being used by multiple parties that do not trust each other, and thus it may be unwise to give them access to the same exception, given that exceptions are generally mutable-- especially to the extent that we think that one might make program logic decisions based on any mutable state in a lower-level cause exception.
The stack trace of any exception is completely mutable, but that seems like a lesser concern. {{RemoteException}}, {{ActivataionException}}, and certain serialization-related {{IOException}} subclasses have public fields, although they seem unlikely to be thrown in this particular situation. {{org.ietf.jgss.GSSException}} has a public method to set the minor error code and message (but not the major...). Another more general issue is that any exception that hasn't had its cause set can be set by anyone with a reference to it with any arbitrary cause.
Despite the desire to provide as much possibly helpful debugging information as possilbe in exception traces, it might be prudent to try to prevent this sharing of access to cause exception across multiple users.
> (mux) low-level cause exceptions thrown to multiple parties that don't trust eac
> --------------------------------------------------------------------------------
>
> Key: RIVER-138
> URL: https://issues.apache.org/jira/browse/RIVER-138
> Project: River
> Issue Type: Bug
> Components: net_jini_jeri
> Affects Versions: jtsk_2.0
> Reporter: Peter Jones
> Priority: Minor
>
> Bugtraq ID [4858644|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4858644]
> When an entire mux connection goes down because of an exception, that exception is recorded, and that recorded exception is later used as the lower-level "cause" of {{IOExceptions}} that get thrown from I/O operations on the connection-- such as reading or writing on individual sessions' streams. This occurrence is made much more likely with the fix for [4856965|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4856965], although it actually could happen before that fix too (I just realized). The same connection could be being used by multiple parties that do not trust each other, and thus it may be unwise to give them access to the same exception, given that exceptions are generally mutable-- especially to the extent that we think that one might make program logic decisions based on any mutable state in a lower-level cause exception.
> The stack trace of any exception is completely mutable, but that seems like a lesser concern. {{RemoteException}}, {{ActivataionException}}, and certain serialization-related {{IOException}} subclasses have public fields, although they seem unlikely to be thrown in this particular situation. {{org.ietf.jgss.GSSException}} has a public method to set the minor error code and message (but not the major...). Another more general issue is that any exception that hasn't had its cause set can be set by anyone with a reference to it with any arbitrary cause.
> Despite the desire to provide as much possibly helpful debugging information as possilbe in exception traces, it might be prudent to try to prevent this sharing of access to cause exception across multiple users.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.