JEP 411, removal of finalizers, a path forward.

[Peter Firmstone]

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.