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) <[email protected]> Date: lun. 3 juin 2019 à 08:48 Subject: [jira] [Commented] (BVAL-176) setAccessible handling is broken for multithreaded apps with SecurityManager To: <[email protected]> [ 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)
