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.
, 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)?
Chris CranfordApril 7, 2017 at 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.
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.