Guard log4j logging calls from needed security permissions

[rjernst]

Log4j needs some security manager permissions, for example to write to a file, or read configuration in an env variable. We make log4j available to all Elasticsearch plugins, but those plugins don't necessarily have all the necessary permissions, especially in the context of reduced permissions (eg ingest attachment reduces permissions when calling Tika code, but Tika code may still log).

We should improve how our log4j loggers handle permissions, so that calling code does not need to worry about the permissions necessary for log4j.

[elasticsearchmachine]

Pinging @elastic/es-core-infra (Team:Core/Infra)

[rjernst]

One idea is to have our own LoggerContextFactory. This would allow us to wrap all Logger implementations, so that calls to isEnabled and logMessage are guarded.

@pgomulka @ChrisHegarty Wdyt? Will that granularity be too performance sensitive for doPriv calls?

[ChrisHegarty]

One idea is to have our own LoggerContextFactory. This would allow us to wrap all Logger implementations, so that calls to isEnabled and logMessage are guarded.

@pgomulka @ChrisHegarty Wdyt? Will that granularity be too performance sensitive for doPriv calls?

I think that the performance aspect should be minimal, if at all, and amortised once the implementation is static and non-capturing. The overhead of putting a doPriv on the stack should be largely insignificant. In the case where a permission check is actually performed, checking the code sources from a truncated stack should be faster.