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.