<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>My thoughts on how to proceed with this is:</p>
<ol>
<li>Develop authorization layer security provider services in
OpenJDK, back port it to Java 8 and Java 11 (these provide most
of the utilised functionality of SecurityManager, allowing
developers to only implement those which they need, without
enabling SecurityManager and editing policy files).<br>
</li>
<li>Remove SecurityManager, Policy and Policy provider in OpenJDK
19.</li>
<li>Leave AccessController and AccessControlContext in place,
provide a security property that allows the stack walk to be
disabled (One ProtectionDomain to represent all code in JVM,
without any permissions, later making it the default, while
allowing it to be enabled) and continue to inject user Subject
principles using SubjectDomainCombiner for JAAS compatibility.
Developers can implement just the authorization they feel
necessary for users and develop their own configuration, or
adapt existing.<br>
</li>
<li>At some point, preferably when StackWalker has equivalent
performance, replace the internals of AccessController.</li>
</ol>
<p>Gut feel is that removal of AccessController,
AccessControlContext and DomainCombiner causes carnage with JAAS,
it's a lot to deal with, SecurityManager and Policy, I don't need
them if I've got authorization layer hooks in the JVM.<br>
</p>
<p>I wouldn't want to see SecurityManager and Policy be neutralized,
it's better to remove it and fail early so people update their
software, there's a risk they may update without realizing it's no
longer fully functional. Get rid of the baggage so people can
start fresh with better practices.<br>
</p>
<p>Note that I'll be implementing a full authorization layer based
on least privilege principles, that still utilizes a stack walk.
I won't use the standard Java Permission implementations, as I'd
like to do things a little differently, for usability reasons,
this will do everything I need at least. If the authorization
layer is back ported, then I can support all current versions.
My policy files are generated, so I don't need permission
implementations to remain compatible.</p>
<p>Whatever happens with JAAS will need to be backported, so we can
support all versions.<br>
</p>
<p>Regards,</p>
<p>Peter.<br>
</p>
<div class="moz-cite-prefix">On 14/06/2021 3:54 pm, Alan Bateman
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com">cc'ing
security-dev as that is the mailing list to use for this JEP.
<br>
<br>
This JEP is the first of several in a multi-release/multi-year
effort. It's way too early to give any guess as to when the APIs
will be removed. As the JEP says, future releases may degrade the
SM APIs so that System.getSM returns always returns null or
AccessController::doPriv just runs the action. This should mean
that libraries that are compiling to older releases should
continue to compile and run on those releases. When they run on
some future release that degrades the implementation then it will
be as if there is no SM. So I would say the impact is little to
none for libraries for the foreseeable future.
<br>
<br>
-Alan
<br>
<br>
<br>
On 13/06/2021 21:28, Rafael Winterhalter wrote:
<br>
<blockquote type="cite">I am currently looking into how I should
address JEP 411 in my library Byte
<br>
Buddy and I find it rather challenging. The problem I am facing
is that I
<br>
know of several users who rely on the security manager in their
Java 8/11
<br>
applications. I would like to continue to support those users'
use cases as
<br>
long as I support Java versions that contain the security
manager, which
<br>
will be for many years to come. At the same time, I would like
to address
<br>
the announced removal of the API and make sure that Byte Buddy
can work
<br>
without it prior to the deadline when the library in its current
state
<br>
would no longer link.
<br>
<br>
From my understanding of the intention of JEP 411, the API was
supposed to
<br>
be stubbed – similar to Android’s stubbing of the API - rather
than being
<br>
removed. However, with the announced deprecation for removal of
<br>
AccessController and SecurityManager, I understand that I would
need to
<br>
fully remove the dispatching to work with future Java versions.
<br>
<br>
Furthermore, it is difficult to create a working facade for
dispatching to
<br>
the security manager only if it is available. Methods like
<br>
AccessController.doPrivileged are caller sensitive and by adding
a utility
<br>
to a library, this utility would leak to any potential user. It
would
<br>
therefore require package-private dispatchers for any relevant
package,
<br>
which would lead to a lot of copy-paste to retain backwards
compatibility
<br>
(given that a library cannot assume to be run as a module).
<br>
<br>
Finally, removing the API would mean that Byte Buddy versions of
the last
<br>
ten years would no longer link in future JDKs. For Byte Buddy
where new
<br>
Java versions often require an update, that might not be a big
issue but
<br>
many other libraries do support the API, I don’t feel it would
be a rather
<br>
severe restriction and cause unnecessary breakage if API is
removed, rather
<br>
than stubbed. I am thinking of libraries like Netty here which
are rather
<br>
omnipresent and would suddenly no longer link, a concept that is
unlikely
<br>
intuitive to a lot of developers.
<br>
<br>
Therefore, my question is: should SecurityManager,
AccessController and the
<br>
Policy APIs really be deprecated for removal? Rather, I think
that the APIs
<br>
should be deprecated, but be retained with stubbed
implementations.
<br>
System.getSecurityMananger would then always return null.
<br>
System.setSecurityManager on the other hand could be deprecated
for
<br>
removal. This way, existing code could continue to work as if
the security
<br>
manager is not active, which already is the common scenario and
would not
<br>
cause any disruption at the small price of keeping a handful of
some
<br>
stubbed classes.
<br>
<br>
Thanks for advice on how this is intended to be handled by
library
<br>
developers like me.
<br>
Best regards, Rafael
<br>
</blockquote>
<br>
</blockquote>
<pre class="moz-signature" cols="72">--
Regards,
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.</pre>
</body>
</html>