[External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

[Peter Firmstone]

Because people have been treating it like a sandbox.

Since it will take a number of years, can we at least consider my 
proposal and give it a try?  It may reduce the burden in the interim.

So this step deprecates it for removal, can we create a JEP for 
replacing the SecurityManager with AccessAssistant while retaining 
AccessController and AccessControlContext?

It's also true that Permisssion's are more numerous than necessary, 
because it has been treated like a sandbox.

If we rename and treat it like access control instead, we can reduce the 
burden, simplify permissions, provide tooling and make it much better 
than it is today.

We've been doing exactly that for years, and we knew the Java PolicyFile 
code was bad, but we never realised that JDK developers saw it in this 
light.

If I had realised that , I would have stepped in years ago to fix it. 
Maybe we got complacent because nothing was ever removed from Java for a 
very long time.

We've been using it silently and efficiently for years.

Regards,

Peter.


On 18/05/2021 7:13 pm, Alan Bateman wrote:
>
>
> On 18/05/2021 08:36, Peter Firmstone wrote:
>> :
>>
>> It's a perception issue, I understand, but we can fix that far less 
>> painfully.
>
> With respect, I don't see a viable route here. SM/AccessController and 
> most of that security architecture has been an albatross around our 
> necks for years. This JEP is the first step in pulling the JDK out of 
> the sandboxing and policy enforcement business. It will take several 
> releases and years to get there. Yes, it will be painful for those 
> that have embraced this architecture but there will be years of 
> supported releases to plan or develop alternatives. There is a wider 
> group that have been using the SM as a means to intercept network, 
> file and several other operations. This is an area that might need to 
> be exploded further to see if an alternative solution is imported for 
> the JDK to provider. We don't think that this needs to be fully 
> explored and decided on before making progress on the deprecation.
>
> -Alan

-- 
Regards,
  
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.