Default MODE_INHERITABLETHREADLOCAL leads to security issue when using threads.

[robertoschwald]

Steps to Reproduce

1. Use MODE_INHERITABLETHREADLOCAL which is default since 3.2.1
2. Use thread pools, e.g. trigger an EventBus message and use doWithAuth() in the consumer
3. The security context set in doWithAuth() is set ONCE in the message Thread. Subsequent doWithAuth() have no effect, as the SecurityContext is already set in the Thread (inherited)

Expected Behaviour

It is possible to set the Security Context in a security save way, especially when using EventBus messages. Otherwise it leads to security issues, as you execute code in the SecurityContext of former users.
See PR test case line https://github.com/grails-plugins/grails-spring-security-core/pull/584/files#diff-c4f5453b9b67bb17e9f9d746dd212afaR258

Actual Behaviour

SecurityContext is set and inherited once and cannot be overwritten. This is approved by Pivotal. They recommend to not use MODE_INHERITABLETHREADLOCAL in pooled environments. spring-projects/spring-security#6856 (comment)

Environment Information

• Operating System: Linux, macOS
• GORM Version: 6
• Grails Version (if using Grails): 3.3.9, 3.3.10
• JDK Version: 8

Example Application

• See PR Showcase thread inheritance pitfalls and include hint in documentation #584

I highly recommend to change the potentially insecure default MODE_INHERITABLETHREADLOCAL back to MODE_THREADLOCAL as a safe default. It imho does not work as intended when using events.