[FEATURE] Additional investigation why OpenSAML 4.3.0 wants to use intenal OpenSearch permission

[willyborankin]

Is your feature request related to a problem?
After switching to OpenSAML version 4.3.0. We found out that 2 additional properties need to be added to the security plugin policy file (the problem was fixed here #2987).
permission java.util.PropertyPermission "*" "read,write"; - is not a big deal since it just asks for access to the internal OpenSAML classes and JDK java.lang.ref.Cleaner
while
permission org.opensearch.secure_sm.ThreadPermission "modifyArbitraryThread - is the internal OpenSearch permission and technically we can't use it. Instead permission java.lang.RuntimePermission "modifyThread"; must be used.

What solution would you like?
To move forward with OpenSAML 4.3.0 we need investigate why it uses
permission org.opensearch.secure_sm.ThreadPermission "modifyArbitraryThread.

Do you have any additional context?
Add any other context or screenshots about the feature request here.

[peternied]

[Triage] Thanks for filing, it would be good to have an understanding of the isolation/exposure model of this dependency

[willyborankin]

@cwperks seems like i found the root cause of the problem. OS tries to check permissions for InnocuousThread which appeared in JDK19. and it does not need to do it since they do not inherit any Access Control Context and therefore have no permissions. I will prepare PR for OpenSearch.

[cwperks]

Nice find @willyborankin!

I'm trying to get to the root of a separate permissions issue related to the JJWT 0.10.x -> 0.11.x upgrade. This PR was required on 2.x, but not required on main and I'm unsure why.

[reta]

@willyborankin I think we could close this one, right?

[willyborankin]

@willyborankin I think we could close this one, right?

Yes