<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Thanks Ron, reply inline.<br>
</p>
<div class="moz-cite-prefix">On 3/08/2021 6:48 pm, Ron Pressler
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:47D86F98-369E-4B25-84BE-185931B99E53@oracle.com">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On 3 Aug 2021, at 06:48, Peter Firmstone <a class="moz-txt-link-rfc2396E" href="mailto:peter.firmstone@zeus.net.au"><peter.firmstone@zeus.net.au></a> 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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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. </pre>
</blockquote>
<p>I'd limit changes to:</p>
<ol>
<li>Make the stack walk optional (via command line argument to
disable it).</li>
<li>Remove Thread's inherited context, replace it with an
unprivileged context.</li>
</ol>
<p>This would allow us to use the API for virtual threads, eg to
obtain Subject credentials to authenticate TLS connections.</p>
<p>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.</p>
<p>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.<br>
</p>
<blockquote type="cite"
cite="mid:47D86F98-369E-4B25-84BE-185931B99E53@oracle.com">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
Just performed a search for java.security.AccessController on GitHub, got 1,398,418 results for Java:
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.
</pre>
</blockquote>
<p>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.<br>
</p>
<p>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.</p>
<p>Someone else may only be concerned with network connections, so
they only implement and register a guard for that.</p>
<p>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.</p>
<p>It is suitable, for Subject's only or code and Subject's.<br>
</p>
<p>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.).<br>
</p>
<p>It's also possible to register guards that do fine grained
permission checks, similar to the way Java does now.</p>
<p>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.</p>
<p>You can trust me on this one, I'm experienced with the current
API and have pushed it to all sorts of limits.<br>
</p>
<p>Cheers,</p>
<p>Peter.<br>
</p>
</body>
</html>