bval-dev mailing list archives

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

             Summary: setAccessible handling is broken for multithreaded apps with SecurityManager
                 Key: BVAL-176
             Project: BVal
          Issue Type: Bug
    Affects Versions: 2.0.0, 1.1.2
            Reporter: Tomasz Wysocki
             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.

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
|      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
|     nicely or at all with other frameworks (like spring for instance).

This message was sent by Atlassian JIRA

View raw message