Inline.
On 26/06/2021 1:46 pm, Peter Firmstone wrote:
Inline below.
On 26/06/2021 1:11 pm, Peter Firmstone wrote:
One more proposed change inline:
On 26/06/2021 12:58 pm, Peter Firmstone wrote:
Summary of Proposed Changes:
1. 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.
2. 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.
3. JDK code, no longer call Permission implementations directly,
instances obtained using GuardFactory, only when enabled in the
java.security configuration file.
4. 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.
5. 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.
6. 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.
7. 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
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.
Since the doPrivileged methods are utilised by other methods in
AccessController, they should be made private when finally deprecated
for removal.
I have also just noticed a bug in AccessController.AccHolder.innocuousAcc.
I need to make some clarifications here:
The ProtectionDomain::getPermissions() method determines whether a
domain is privileged if it contains AllPermission.
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.
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.
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.
This is incorrect, as the ProtectionDomain contains a null
PermissionCollection, my mistake.
However I still propose it be changed, due to the association of a null
CodeSource with bootstrap ClassLoader domains.
It is generally understood that a ProtectionDomain with a null
CodeSource is a system ProtectionDomain loaded by the bootstrap
ClassLoader.
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.
8. Deprecate for removal the CodeSource::implies method.
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.
10. Deprecate for removal AccessController::checkPermission and
AccessControlContext::checkPermission methods.
11. Undeprecate AccessController, AccessControlContext,
DomainCombiner, SubjectDomainCombiner and Subject::doAs methods,
while deprecating for removal methods stated in items above.
To clarify what an *unprivileged* AccessControlContext is:
An instance of AccessControlContext, that contains a single
element array, containing a ProtectionDomain, with a non null
CodeSource, containing a null URL.
Retention of AccessController, AccessControlContext, DomainCombiner
and SubjectDomainCombiner and Subject::doAs methods.
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.
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.
Regards,
Peter Firmstone.
On 25/06/2021 3:59 pm, Peter Firmstone wrote:
Thanks Dalibor,
Would targeting Java 18 be practical?
Also it won't take long to code a prototype, just not sure of the
process.
Cheers,
Peter.
On 24/06/2021 9:30 pm, Dalibor Topic wrote:
On 24.06.2021 04:24, Peter Firmstone wrote:
Thanks Andrew,
For the simple case, of replacing the SecurityManager stack walk,
one could use reflection.
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.
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.
cheers,
dalibor topic
--
Regards,
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.
