[External] : Re: JEP 411, removal of finalizers, a path forward.

[Peter Firmstone]

Thanks Ron, reply inline.

On 3/08/2021 6:48 pm, Ron Pressler wrote:
>
>> On 3 Aug 2021, at 06:48, Peter Firmstone <peter.firmstone at zeus.net.au> wrote:
>>
>>
>> We can still use these without an SM, Policy or Permissions for authorization decisions, as mentioned previously I'd replace the inherited thread context with an unprivileged context, and also allow the stack walk to be disabled for people only using Subject.
>>
> I think what you mean is that you can envision using the same API points for a different, but reasonably similar
> role to the one they have. But that would mean changing the behaviour of existing classes, possibly making some
> final classes non-final, in non-trivial ways.

I'd limit changes to:

 1. Make the stack walk optional (via command line argument to disable it).
 2. Remove Thread's inherited context, replace it with an unprivileged
    context.

This would allow us to use the API for virtual threads, eg to obtain 
Subject credentials to authenticate TLS connections.

It also means that for someone implementing guard checks, that these 
only need check the thread stack back to the last doPrivileged call, or 
the start of the thread, in the latter case it will have no privileges.  
It fixes the viral permission check problem, usually doPrivileged calls 
are short and sweet.

It may require the addition of doPrivileged calls where they're 
currently missing (and should have been used), where they've been 
responsible for viral permission checks.

>
>> Just performed a search for java.security.AccessController on GitHub, got 1,398,418 results for Java:
>>
> The plan is to degrade these into no-ops until such time as most of those usages disappear, not to imbue
> those lines of code with new meaning. The actual removal of the API elements might be a long way off,
> but, becoming no-ops before then, the JDK and libraries will be free to remove those usages.

No new meanings, the same as they have now is sufficient, just we leave 
the granularity of the checks to the developers of guards and provide a 
means by which guards can be registered for common check points that 
developers request (perhaps via a poll), rather than all existing 
permission check points.  Keeping in mind that we are not trying to 
isolate code, but perform authorization access checks, as well as 
provide credentials for authentication.

For example, if someone is only concerned with stopping the JVM from 
exiting, then they only implement a guard for that particular hook, the 
actual code that needs to call System::exit, then calls a doPrivileged 
method before doing so.  The guard need only check the domain on the 
stack is the one it expects, which could be based on Principal, 
CodeSource, Module or ClassLoader etc, they may also chose to implement 
something more complex.

Someone else may only be concerned with network connections, so they 
only implement and register a guard for that.

So basically we don't dictate how to implement guards or policy, we just 
leave enough in place, to ensure that a minimalist authorization access 
control api is common among all implementations on all Java versions.

It is suitable, for Subject's only or code and Subject's.

The doPrivileged call simply indicates the code is requesting to do 
something that might be privileged, or needs to provide credentials for 
authentication, as it does now, but it's the light version of the stack 
walk, if doPrivileged is not called, then the context will have an 
unprivileged domain on the stack (that initialized when Thread was 
created.).

It's also possible to register guards that do fine grained permission 
checks, similar to the way Java does now.

Then there's the use case, or registering no guards at all, and 
disabling the stack walk, and only using the api to obtain and preserve 
Subject credentials for authentication.

You can trust me on this one, I'm experienced with the current API and 
have pushed it to all sorts of limits.

Cheers,

Peter.