bval-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tomasz Wysocki (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (BVAL-176) setAccessible handling is broken for multithreaded apps with SecurityManager
Date Sun, 02 Jun 2019 22:46:00 GMT

     [ https://issues.apache.org/jira/browse/BVAL-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Tomasz Wysocki updated BVAL-176:
--------------------------------
    Description: 
Currently when using security manager field/method accessible flag will be reset back to false.

This does not work for multithreaded apps due to lack of synchronization between threads.


The effect is exception while validating due to invalid access to protected or private members
of target object.

Workaround is to make all validated members public or synchronize on Validator instance.

This issue contains a test case to show the effect when security manager is installed and
there is no synchronization as well as a patch to 1.1.2.

This issue applies to bval2 as well but I haven't made a patch.

Below is proposed rationale:

Remove ability to reset accessible flag when security manager is present
     
     This feature will not work without some synchronization on the
     reflection data itself in multithreaded environment.
     
     Therefore the feature has been removed due to following concerns:
     
     1. resetting accessible flag for security manager does not mean that for
     short period of time the flag is not actually set and bad code could
     exploit that - therefore resetting accesible back is not really making
     it unaccessible to other code - this is design flaw. If accessible flag
     would be per thread it would work much better.
     
     2. since accessible flag is global it would require synchronization to make it work
correctly,
      which is costly. Current implementation just breaks for SM present case
     - it throws 'inaccessible' exceptions since it does not synchronize at
     all.
     
     3. there is no saying what would need to be synchronized (probably the
     field or method reflected instances but it is not specified). Therefore
     synchronizing it would work only within scope of a single framework
     (bval).
     
     4. other frameworks typically don't reset back accessible and just keep
     the flag set. Therefore any synchronization mechanism specific to bval would not
cooperate
     nicely or at all with other frameworks (like spring for instance).

  was:
Currently when using security manager field/method accessible flag will be reset back to false.

This does not work for multithreaded apps due to lack of synchronization between threads.


The effect is exception while validating due to invalid access to protected or private members
of target object.

Workaround is to make all validated members public or synchronize on Validator instance.

This issue contains a test case to show the effect when security manager is installed and
there is no synchronization as well as a patch to 1.1.2.

This issue applies to bval2 as well but I haven't made a patch.

Remove ability to reset accessible flag when security manager is present
|     
|     This feature will not work without some synchronization on the
|     reflection data itself in multithreaded environment.
|     
|     Therefore the feature has been removed due to following concerns:
|     
|     1. resetting accessible flag for security manager does not mean that for
|     short period of time the flag is not actually set and bad code could
|     exploit that - therefore resetting accesible back is not really making
|     it unaccessible to other code - this is design flaw. If accessible flag
|     would be per thread it would work much better.
|     
|     2. since accessible flag is global it would require synchronization to make it work
correctly,
|      which is costly. Current implementation just breaks for SM present case
|     - it throws 'inaccessible' exceptions since it does not synchronize at
|     all.
|     
|     3. there is no saying what would need to be synchronized (probably the
|     field or method reflected instances but it is not specified). Therefore
|     synchronizing it would work only within scope of a single framework
|     (bval).
|     
|     4. other frameworks typically don't reset back accessible and just keep
|     the flag set. Therefore any synchronization mechanism specific to bval would not
cooperate
|     nicely or at all with other frameworks (like spring for instance).


> setAccessible handling is broken for multithreaded apps with SecurityManager
> ----------------------------------------------------------------------------
>
>                 Key: BVAL-176
>                 URL: https://issues.apache.org/jira/browse/BVAL-176
>             Project: BVal
>          Issue Type: Bug
>    Affects Versions: 1.1.2, 2.0.0
>            Reporter: Tomasz Wysocki
>            Priority: Major
>             Fix For: 1.1.3
>
>
> Currently when using security manager field/method accessible flag will be reset back
to false.
> This does not work for multithreaded apps due to lack of synchronization between threads.

> The effect is exception while validating due to invalid access to protected or private
members of target object.
> Workaround is to make all validated members public or synchronize on Validator instance.
> This issue contains a test case to show the effect when security manager is installed
and there is no synchronization as well as a patch to 1.1.2.
> This issue applies to bval2 as well but I haven't made a patch.
> Below is proposed rationale:
> Remove ability to reset accessible flag when security manager is present
>      
>      This feature will not work without some synchronization on the
>      reflection data itself in multithreaded environment.
>      
>      Therefore the feature has been removed due to following concerns:
>      
>      1. resetting accessible flag for security manager does not mean that for
>      short period of time the flag is not actually set and bad code could
>      exploit that - therefore resetting accesible back is not really making
>      it unaccessible to other code - this is design flaw. If accessible flag
>      would be per thread it would work much better.
>      
>      2. since accessible flag is global it would require synchronization to make
it work correctly,
>       which is costly. Current implementation just breaks for SM present case
>      - it throws 'inaccessible' exceptions since it does not synchronize at
>      all.
>      
>      3. there is no saying what would need to be synchronized (probably the
>      field or method reflected instances but it is not specified). Therefore
>      synchronizing it would work only within scope of a single framework
>      (bval).
>      
>      4. other frameworks typically don't reset back accessible and just keep
>      the flag set. Therefore any synchronization mechanism specific to bval would
not cooperate
>      nicely or at all with other frameworks (like spring for instance).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message