JDK 19 innocuous reaper threads

[Alan Bateman]

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