JEP411: Missing use-case: Monitoring / restricting libraries

[Alan Bateman]

On 31/05/2021 08:11, Peter Firmstone wrote:
> :
>
> I think also that many more people are using SecurityManager than 
> OpenJDK realises, and they're not using it how OpenJDK recommends 
> either, (AllPermission granted to trusted code, and sandbox untrusted 
> code model of Applets is not how we use it) people are using POLP, 
> it's just that no one reports back to OpenJDK because they are only 
> editing policy files, it will work with any library out there now, 
> there's nothing to write back about.  It's pretty clear that OpenJDK 
> devs don't use it, but they do have to manage doPrivileged and 
> preserving context across tasks and threads.
>
> And there are static analysis tools in Spotbugs to identify 
> doPrivileged bugs, but someone has recently suggested removing them 
> thanks to this JEP?  Does OpenJDK use static analysis.  I think if you 
> did you'd find plenty of latent bugs.

I don't think the SM is approachable by most developers. I've sat 
through several embarrassing sessions at conferences over the years 
where a speaker attempted to get something non-trivial to work with the 
SM enabled. More often than not they had to deal with libraries that had 
never been run with a SM before and it was whack-a-mole to get them to 
run. As you know, any library or framework with callbacks means careful 
use of doPrivileged to avoid needing to grant permissions to every 
component on the stack. You mention capturing and re-asserting contexts 
across threads, this is just way too complex for most developers. My 
guess is that if we had enabled the SM by default 20 years ago then it 
would be a different discussion today. This is not to say that there 
isn't some usage, the flurry of mails here over the last month does show 
that there is some usage. The SM survey in 2018 showed that there was 
some usage too.

I can't speak for all OpenJDK contributors but Oracle contributors do a 
massive amount of analysis and static analysis before proposing to 
deprecate or removing anything. It's often much harder to remove 
something that add it and I don't think anyone has proposed deprecating 
or removing anything without a strong case.

-Alan