You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Kristian Waagan <Kr...@Sun.COM> on 2006/03/01 18:46:11 UTC
Re: [jira] Created: (DERBY-1069) Client should unwrap exceptions
thrown in privilege blocks rather than throwing the
java.security.PrivilegedActionException
Daniel John Debrunner (JIRA) wrote:
> Client should unwrap exceptions thrown in privilege blocks rather than throwing the java.security.PrivilegedActionException
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1069
> URL: http://issues.apache.org/jira/browse/DERBY-1069
> Project: Derby
> Type: Bug
> Components: Network Client
> Reporter: Daniel John Debrunner
>
>
> Can lead to misunderstanding the root cause of the problem.
>
Hi Dan,
Are you thinking of the problem that a new exception is created in the
try-catch block around the
'AccessController.doPrivileged(PrivilegedExceptionAction)', and thus the
stacktrace for the original exception is "polluted"?
(or lost if the original exception is not set as cause for the new one)
If we are not to throw the 'PrivilegedActionException', I guess we are
left with two choices:
1) Writing code for casting the 'PrivilegedActionException' to other
exception types in the catch-block and re-throwing it.
2) Creating a new exception and setting
'PrivilegedActionException.getException()' as cause for this.
Any opinions on the approaches above?
Have I missed anything?
--
Kristian
Re: [jira] Created: (DERBY-1069) Client should unwrap exceptions
thrown in privilege blocks rather than throwing the java.security.PrivilegedActionException
Posted by Daniel John Debrunner <dj...@apache.org>.
Kristian Waagan wrote:
> Daniel John Debrunner (JIRA) wrote:
>
>> Client should unwrap exceptions thrown in privilege blocks rather than
>> throwing the java.security.PrivilegedActionException
>> ---------------------------------------------------------------------------------------------------------------------------
>>
>>
>> Key: DERBY-1069
>> URL: http://issues.apache.org/jira/browse/DERBY-1069
>> Project: Derby
>> Type: Bug
>> Components: Network Client Reporter: Daniel John Debrunner
>>
>>
>> Can lead to misunderstanding the root cause of the problem.
>>
>
> Hi Dan,
>
> Are you thinking of the problem that a new exception is created in the
> try-catch block around the
> 'AccessController.doPrivileged(PrivilegedExceptionAction)', and thus the
> stacktrace for the original exception is "polluted"?
> (or lost if the original exception is not set as cause for the new one)
>
> If we are not to throw the 'PrivilegedActionException', I guess we are
> left with two choices:
> 1) Writing code for casting the 'PrivilegedActionException' to other
> exception types in the catch-block and re-throwing it.
>
> 2) Creating a new exception and setting
> 'PrivilegedActionException.getException()' as cause for this.
>
>
> Any opinions on the approaches above?
> Have I missed anything?
Here's the issue as I see it, doesn't seem to fit with what you said,
but I wasn't being clear.
Without privileged blocks I would do something like
try {
fis = new FileInputStream(name);
} catch (IOException ioe)
{
// do something with ioe.
}
Most likely the error gets displayed to the user in some form that
indicates it was an IOException, therefore they are focussed on what the
problem is, wrong path name etc.
With privileged blocks the engine does something something like
(pseudo code)
try {
<priv block fis = new FileInputStream(name); /priv block>
} catch (PrivilegedActionException pae)
{
// I know the execption is an IOException because
// that's all that can be raised in the priv block
IOException ioe = pae.getException();
// do something with ioe.
}
Again the exception displayed to the end-user is an IOException allowing
them to correctly focus.
The client seems to be doing something like (general approach here):
try {
<priv block fis = new FileInputStream(name); /priv block>
} catch (PrivilegedActionException pae)
{
// do something with pae.
}
Now, the user receives a java.security.PrivilegedActionException, a good
chance their mind set is now that they are seeing a security issue, and
start looking at their policy file, security manager etc. When in
reality the PrivilegedActionException is only a coding mechanism to
handle checked exception in a priv block. Displaying it provides no
value to anyone, much better to take the engine approach and remove it
from the picture.
Hope this helps,
Dan.