On 2/08/2021 4:48 am, Alan Bateman wrote:
On 01/08/2021 15:28, Uwe Schindler wrote:
:
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!
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".
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.
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.
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.
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.
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 /special case/.
Regards,
Peter.
