[
https://issues.apache.org/jira/browse/BVAL-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16854274#comment-16854274
]
Tomasz Wysocki commented on BVAL-176:
-------------------------------------
I would be grateful for 1.1.x maintenance branch (fabb6c4) and prompt release
of 1.1.3 to avoid custom version.
I will do a master fix shortly (second PR).
> 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
>
> Attachments: ReflectionAccessibilityTest.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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 resolution:
> Remove reseting of accessible flag when security manager is present
>
> And rationale:
> 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)
