JEP 411, removal of finalizers, a path forward.
peter.firmstone at zeus.net.au
Mon Aug 2 06:00:48 UTC 2021
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
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/.
More information about the jdk-dev