bval-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Fwd: [jira] [Commented] (BVAL-176) setAccessible handling is broken for multithreaded apps with SecurityManager
Date Mon, 03 Jun 2019 06:51:50 GMT
Hello everyone,

Do you know where are our 1.x tags/branches? Lost in svn migration? Should
we ask infra?

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


---------- Forwarded message ---------
De : Tomasz Wysocki (JIRA) <jira@apache.org>
Date: lun. 3 juin 2019 à 08:48
Subject: [jira] [Commented] (BVAL-176) setAccessible handling is broken for
multithreaded apps with SecurityManager
To: <dev@bval.apache.org>



    [
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)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message