<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Inline.<br>
</p>
<div class="moz-cite-prefix">On 26/06/2021 1:46 pm, Peter Firmstone
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:fe7e5d89-9f62-2893-9cb4-041fc9c068d0@zeus.net.au">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Inline below.<br>
</p>
<div class="moz-cite-prefix">On 26/06/2021 1:11 pm, Peter
Firmstone wrote:<br>
</div>
<blockquote type="cite"
cite="mid:ed9503e3-0fcf-1f66-f147-4e0ed7e96f48@zeus.net.au">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p>One more proposed change inline:<br>
</p>
<div class="moz-cite-prefix">On 26/06/2021 12:58 pm, Peter
Firmstone wrote:<br>
</div>
<blockquote type="cite"
cite="mid:9084f553-7440-de48-2e03-2447ebd280c5@zeus.net.au">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p>Summary of Proposed Changes:</p>
<ol>
<li>GuardFactory & GuardFactorySpi to provide hooks for
authorization checks without SecurityManager or Policy.
(Note GuardFactory should never return null and instead
return a no-op Guard that hotspot can optimize out.<br>
</li>
<li>Existing Permission implementations to be obtained using
GuardFactorySpi implementations, until their removal.
Note that when SecurityManager is stubbed out and
Permission implementations are deprecated for removal,
these should no longer be provided by default, but instead
need to be enabled by entries in the java.security config
file, in preparation for their removal.<br>
</li>
<li>JDK code, no longer call Permission implementations
directly, instances obtained using GuardFactory, only when
enabled in the java.security configuration file.<br>
</li>
<li>Threads (system and virtual) updated to use a singleton
*unprivileged* AccessControlContext, instead of inherited
AccessControlContext, this is more appropriate for
Executors, the original inherited context was designed
before Executors were introduced.</li>
<li>Deprecation for removal of all Permission
implementations from the JDK platform. The existing
implementations of Permission introduce unnecessary
complexity; they lack sufficient flexibility resulting in
a proliferation of Permission grants required in policy
files and some make blocking network calls.<br>
</li>
<li>Introduce a system property to change AccessController
default behaviour, disable the stack walk by default, but
allow it to be re-enabled with a system property, replace
the stack walk array result of ProtectionDomains with an
*unprivileged* AccessControlContext, the
SubjectDomainCombiner can replace it with a,
AccessControlContext containing a single element array,
containing one ProtectionDomain with Principals. <br>
</li>
<li>AccessController::doPrivileged erases the DomainCombiner
by default, deprecate these methods, retain
doPrivilegedWithCombiner methods that preserve the
SubjectDomainCombiner. Developers should replace their
doPrivileged methods with doPrivilegedWithCombiner</li>
</ol>
</blockquote>
</blockquote>
<p><br>
</p>
<p>Just thinking out loud, it's possible someone might want to do
perform some task without privileges enabled, that is without
the Subject's principal's. In a system that grants privileges
to code and principals, this is generally unnecessary, as grants
are made to the combination of code and principals. However
while using the doPrivileged methods is possible, to remove
privileges, it would be better to provide an
AccessController::doUnprivileged method instead, which erase the
DomainCombiner and use an *unprivileged* AccessControlContext.<br>
</p>
<p>Since the doPrivileged methods are utilised by other methods in
AccessController, they should be made private when finally
deprecated for removal.</p>
<p>I have also just noticed a bug in
AccessController.AccHolder.innocuousAcc.</p>
</blockquote>
<p><br>
</p>
<p>I need to make some clarifications here:</p>
<p>The ProtectionDomain::getPermissions() method determines whether
a domain is privileged if it contains AllPermission.</p>
<p>Since future implementations might not use Permission's to
determine privileges, and privileges may be determined by
CodeSource or Principal's, a null CodeSource is used to indicate a
domain belonging to the bootstrap ClassLoader.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:fe7e5d89-9f62-2893-9cb4-041fc9c068d0@zeus.net.au">
<p>The innocuous AccessControlContext, is intended to have no
permission, hence it is constructed using the two argument
ProtectionDomain constructor, which causes ProtectionDomain to
not consult the Policy.</p>
<p>However, if a user obtains this ProtectionDomain and asks the
Policy for the ProtectionDomain's permission's by calling
Policy::getPermissions(ProtectionDomain), the Policy will return
AllPermission.<br>
</p>
</blockquote>
<p><br>
</p>
<p>This is incorrect, as the ProtectionDomain contains a null
PermissionCollection, my mistake.</p>
<p>However I still propose it be changed, due to the association of
a null CodeSource with bootstrap ClassLoader domains.<br>
</p>
<blockquote type="cite"
cite="mid:fe7e5d89-9f62-2893-9cb4-041fc9c068d0@zeus.net.au">
<p> </p>
<p>It is generally understood that a ProtectionDomain with a null
CodeSource is a system ProtectionDomain loaded by the bootstrap
ClassLoader.</p>
<p>I propose that innocuous AccessControlContext instead be given
a ProtectionDomain, with a non-null CodeSource, which has a null
URL. This is also considered by the Policy to be unprivileged.<br>
</p>
<br>
<blockquote type="cite"
cite="mid:ed9503e3-0fcf-1f66-f147-4e0ed7e96f48@zeus.net.au">
<blockquote type="cite"
cite="mid:9084f553-7440-de48-2e03-2447ebd280c5@zeus.net.au">
<ol>
</ol>
8. Deprecate for removal the CodeSource::implies method.
<ol>
</ol>
9. Give unique ProtectionDomain's with a meaninful
CodeSource to Java modules mapped to the boot loader, rather
than using a Shared ProtectionDomain with a null CodeSource.<br>
<ol>
</ol>
</blockquote>
<p> 10. Deprecate for removal
AccessController::checkPermission and
AccessControlContext::checkPermission methods.</p>
<p> 11. Undeprecate AccessController, AccessControlContext,
DomainCombiner, SubjectDomainCombiner and Subject::doAs
methods, while deprecating for removal methods stated in items
above.<br>
</p>
<blockquote type="cite"
cite="mid:9084f553-7440-de48-2e03-2447ebd280c5@zeus.net.au">
<p>To clarify what an *unprivileged* AccessControlContext is:</p>
<blockquote>
<p>An instance of AccessControlContext, that contains a
single element array, containing a ProtectionDomain, with
a non null CodeSource, containing a null URL.</p>
</blockquote>
<p>Retention of AccessController, AccessControlContext,
DomainCombiner and SubjectDomainCombiner and Subject::doAs
methods.</p>
<p>Stubbing of SecurityManager and Policy, for runtime
backward compatibility. Update ProtectionDomain::implies
method, to *not* consult with the Policy. Note it's
possible to get access to the ProtectionDomain array
contained within AccessControlContext using a
DomainCombiner.<br>
</p>
<p>This is backward compatible with existing usages of JAAS
and least painful method of transition for all concerned as
well as allowing complete flexibility of implementation.</p>
<p>Regards,</p>
<p>Peter Firmstone.<br>
</p>
<div class="moz-cite-prefix">On 25/06/2021 3:59 pm, Peter
Firmstone wrote:<br>
</div>
<blockquote type="cite"
cite="mid:2f315680-1cdb-1694-34a3-95312bf42ca7@zeus.net.au">Thanks
Dalibor, <br>
<br>
Would targeting Java 18 be practical? <br>
<br>
Also it won't take long to code a prototype, just not sure
of the process. <br>
<br>
Cheers, <br>
<br>
Peter. <br>
<br>
<br>
On 24/06/2021 9:30 pm, Dalibor Topic wrote: <br>
<blockquote type="cite">On 24.06.2021 04:24, Peter Firmstone
wrote: <br>
<blockquote type="cite">Thanks Andrew, <br>
<br>
For the simple case, of replacing the SecurityManager
stack walk, one could use reflection. <br>
<br>
Thank you for also confirming that is not possible (or
at least very unlikely) to add a GuardBuilder to Java 8,
the proposal is for JDK code to use a provider
mechanism, to intercept permission checks, so custom
authentication layers can be implemented, this could be
accepted in future versions of Java, but not existing.
As it is said, there is no harm in asking. <br>
</blockquote>
<br>
Generally speaking, adding any public APIs to a platform
release after its specification has been published, is
always going to be a very tall order involving the JCP,
among other things. It's not really worth it, when other
technical solutions, such as multi-release JARs, already
exist, that alleviate the necessity. <br>
<br>
cheers, <br>
dalibor topic <br>
<br>
</blockquote>
</blockquote>
</blockquote>
<pre class="moz-signature" cols="72">--
Regards,
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.</pre>
</blockquote>
</blockquote>
<pre class="moz-signature" cols="72">
</pre>
</body>
</html>