bval-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Romain Manni-Bucau (JIRA)" <>
Subject [jira] [Commented] (BVAL-176) setAccessible handling is broken for multithreaded apps with SecurityManager
Date Fri, 07 Jun 2019 11:23:00 GMT


Romain Manni-Bucau commented on BVAL-176:

linking to INFRA-18565 since we need that to apply on 1.1.x

> setAccessible handling is broken for multithreaded apps with SecurityManager
> ----------------------------------------------------------------------------
>                 Key: BVAL-176
>                 URL:
>             Project: BVal
>          Issue Type: Bug
>    Affects Versions: 1.1.2, 2.0.0
>            Reporter: Tomasz Wysocki
>            Priority: Major
>             Fix For: 2.0.3
>         Attachments:
>          Time Spent: 40m
>  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

View raw message