Envers integration tests fail when WildFly security manager is enabled

Description

See WFLY-8377 and JBEAP-9597 for details about WildFly integration test failures (linked).

I've looked into this issue and found that Envers uses reflection at run time to obtain constructors, getters, and setters. The helper that is used to obtain these is org.hibernate.internal.util.ReflectHelper which is loaded in the Hibernate ClassLoader. By debugging, I can see that the security check fails because the ReflectHelper ClassLoader is not the TCCL.

Most, if not all, of these constructors, getters, and setters are already stashed in Hibernate tuplizers at deployment time. We can avoid most, hopefully all, of the security exceptions by changing Envers to use the Hibernate tuplizers instead of reflection at run time.

If there are any security exceptions that are left after making these changes, we will look into adding privileged blocks.

Environment

None

Activity

Show:
Chris Cranford
April 7, 2017, 3:47 AM

As discussed on HipChat, the least disruptive change, especially considering we want to backport this to 5.1 is definitely adding PrivilegedAction. This obviously avoids introducing any regression concerns in the 5.1 branch and work on a much cleaner approach moving forward. So I'll submit my PR that introduces these privileged actions for master and if that seems acceptable, we'll integrate that and then cherry-pick it back to 5.1.

I've added as a follow-up for the long-term solution.

Chris Cranford
August 21, 2017, 1:43 PM

, do I understand that we just simply want to roll this into 5.2 and not backport this then to 5.1 (at least not presently)?

Gail Badner
October 19, 2017, 9:25 AM

Fixed in master.

Gail Badner
April 30, 2018, 11:40 PM

Fixed in 5.1 branch as well.

Assignee

Chris Cranford

Reporter

Gail Badner

Fix versions

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Components

Priority

Major
Configure