JDK-8280491 and JEP411

Peter Firmstone peter.firmstone at zeus.net.au
Sat Jun 17 10:12:23 UTC 2023


Thanks Sean.

It's a pity we're not permitted to redesign a light weight authorization 
mechanism from the ashes of the existing system, something that allowed 
the use of PrivilegedAction et al.

The reality is, authorization could be so much simpler and more useful 
than it is today, especially if outside of privileged action's, no 
privileges were granted at all, it addresses problems with preservation 
of context over threads and executors.

The reason the original designers chose to allow granting permission 
outside of privileged actions, was to make it compatible with existing 
deployments, but since SM didn't need to be enabled and often wasn't 
enabled by default, it probably wasn't the right choice, as it led to 
the viral permission problem.

The remaining use case for authorization is to allow the coming together 
of trusted parties within one JVM, for access decisions and we could so 
easily make it high scaling, performant, simpler with far better 
tooling, but sadly, the applet use case shone so brightly people are 
unable to see other uses for it.

OpenJDK still relies on DNS for identity decisions in SecureClassLoader, 
which is subject to DNS cache poisoning attacks, easily solved using 
RFC3986 and RFC5952 URI normalization, and doesn't it just speed up 
class loading so nicely. ;)   Outside of OpenJDK, some of these things 
were solved over a decade ago and have been thoroughly tested and are 
well understood.   The Jini development branch, inherited from Sun 
Microsystems had comprehensive network deployment, regression and unit 
tests, which significantly contributed to its understanding.

-- 
Regards,
  
Peter

On 17/06/2023 3:33 am, Sean Mullan wrote:
> See also https://bugs.openjdk.org/browse/JDK-8296244
>
> --Sean
>
> On 6/16/23 1:48 AM, Alan Bateman wrote:
>> On 16/06/2023 03:48, Peter Firmstone wrote:
>>> :
>>>
>>> As it isn't yet clear how a Subject context will be preserved across
>>> threads in future version of OpenJDK, (currently we use the
>>> AccessControlContext for that), for example we capture the existing
>>> context, to establish TLS connections in call back communications for
>>> network event listeners.
>>>
>>
>> It's good to think about a Subject.current/callAs re-implemented to use
>> ScopedValue [1], currently in preview with JEP 446 in Java 21.
>> ScopedValue allows for sharing in structured concurrency contexts.
>>
>> -Alan
>>
>> [1]
>> https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/ScopedValue.html 
>>
>> [2] https://openjdk.org/jeps/446



More information about the security-dev mailing list