<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>On 2/08/2021 4:48 am, Alan Bateman wrote:<br>
</p>
<blockquote type="cite"
cite="mid:7e56d243-843c-47b1-53fb-383cade3cd7e@oracle.com">On
01/08/2021 15:28, Uwe Schindler wrote: <br>
<blockquote type="cite" style="color: #007cff;">: <br>
What I figured out: You intend to remove SecurityManager because
it does not fit your latest ideas how Java threads should
behave. I know the main problem is not "SecurityManager is too
complex / too slow / wrongly used /..." -- the main problem of
some OpenJDK people around the Loom project is that it won't
work correctly with those new type of threads. You are now
always arguing against use cases of SecurityManager for the
purpose of secuirty because you just want to hide that the new
"light" threads (aka fibers) in project Loom are incompatible to
the stack-based access control provided by AccessController and
SecurityManager. So the only canard is Project Loom - sorry! <br>
</blockquote>
This isn't right, I don't know where you got that. The only
connection to threads is the unspecified capturing of an access
control context at Thread create time. Loom has been betting that
it will be irrelevant and eventually removed so doesn't capture
it. For the interim it just specifies that virtual threads have
"no permissions". </blockquote>
<p>Alternatively for loom virtual threads; use an unprivileged
context instead of inherited context. A good choice for all
threads actually, not just virtual. Fixes viral permissions,
Executor task vulnerabilities, it requires downstream developers
to add doPrivileged methods before an application can do something
that's privileged and reduces pain for people more focused on
granting privileges to Principals.<br>
</p>
<p>Developers who use SM are reading JEP 411 and interpreting it as
biased towards SM removal, so are looking for an underlying
motivation for SM removal not stated there. I also suspected that
Loom might be the reason at one point.<br>
</p>
<p>From our discussions, my interpretation is that OpenJDK is
constrained by corporate security policy; any issues with
SecurityManager infrastructure will be treated as confidential
security issues and have to be fixed with internal resources.
Community volunteers won't be allowed to handle them. Hence it's
the maintenance burden. I see this maintenance cost as a
bureaucratic management issue, rather than an issue with SM per
se.<br>
</p>
<p>I have previously suggested that SM infrastructure bugs not be
handled as security issues, instead reported as authorization
layer bugs, with any support for sandboxing removed. If it is
true what Andrew Dinn suggests, that OS measures are more
appropriate, then these bugs don't need to be treated as security
issues and can be downgraded, to allow the community using it, to
maintain SM infrastructure instead. This way, it doesn't impact
other developers who don't use it. If Andrew is correct, we can
downgrade bugs in SM code, they are not security bugs in the
traditional sense, if that isn't the case, then Andrew is likely
incorrect.<br>
</p>
<p>Uwe, thanks for speaking up, the more people who speak up about
their use of SM, as an authorization layer, rather than a sandbox
for code with malicious intent, the less OpenJDK will consider
this use of SM is a <i class="moz-txt-slash"><span
class="moz-txt-tag">/</span>special case<span
class="moz-txt-tag">/.</span></i></p>
<p>Regards,</p>
<p>Peter.<br>
</p>
</body>
</html>