On 22/11/2022 15:21, Chris Hegarty wrote:
Hi,
A change in JDK 19, that changed process reaper threads to be
innocuous [1], has had an adverse affect when terminating the
Elasticsearch server [2]. I agree with changing the process reapers to
be innocuous, but just wonder if we're missing a few doPriv blocks.
Additionally, and also in JDK 19, is the welcome improvement of the pid
in the reaper thread name [3], but again I wonder if we're missing a few
doPriv blocks here too.
The issues we're seeing arise from the calls to `setDaemon` and `setName`
outside of doPriv blocks, which can (depending on your security manager
implementation) result in checking the callers permissions, and its
callers permissions, etc, all the way to the thread's inherited access
control context - which is effectively empty for these threads, since
they are innocuous.
I don't remember where we ended up with these kinda calls for innocuous
threads, I'm thinking specifically about `setDaemon` (but `setName`
seems similar) - whether they should be in doPriv or not, given the
default security manager implementation. My feeling is that they should,
since the caller should never be required to hold any specific
permissions for these specific operations [4][5][6] to succeed.
Just to double check, does the ES security manager override
checkAccess(Thread)? That is usually a no-op but if overridden then it
will expose an issue with the thread factory for the "process reaper"
where it attempts changes the daemon status outside of a doPriv block.
-Alan
