Thanks Ron, reply inline.
On 3/08/2021 6:48 pm, Ron Pressler wrote:
On 3 Aug 2021, at 06:48, Peter Firmstone <peter.firmst...@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.
