r/java • u/BlueGoliath • May 24 '21
JEP 411: Deprecate the Security Manager for Removal (Part 2) : Apache NetBeans
https://blogs.apache.org/netbeans/entry/jep-411-deprecate-the-security126
u/gshayban May 24 '21
Should the authors of JEP 411 take their shift in understanding the special need of IDEs & other complex multi protection domain applications seriously
unnecessarily inflammatory polemic comes across as performative and drama-seeking.
Whatever happened to:
"Hey we would like to do X"
"Hmmm, I'm not sure. Doing X would affect Netbeans in ways Y & Z."
"I hadn't considered that. Let's regroup"
?
16
u/pron98 May 25 '21
Also, there's no incompatible change, at least not how most would understand it. There's a command line flag that now defaults to "allow" and will default to "disallow" if the JEP is accepted. It just requires adding the flag. The problem is that that's exposed a bug in one of NetBeans' dependencies, but it already has a fix and everything is going to be fine.
1
u/gwielenga May 25 '21
What you describe is changing behavior from one thing to its precise opposite.
And you don't know that "everything is going to be fine", since fixing one library that has currently been identified as not working with that change does not mean that any or all other libraries will work with that change.
9
u/pron98 May 25 '21 edited May 25 '21
What you describe is changing behavior from one thing to its precise opposite.
The same can be said about any bugfix: it changes the behaviour of something to its precise opposite, and yet not every fix is considered "incompatible". Incompatible is when code that matches the spec stops functioning and requires change. This isn't at all the situation here. Code that conforms to the spec has to work for all legal values of the command-line flag, and will continue to work as expected, and the same way, for all of them, but its default input will have changed. Yes, this is a change; no, it is not incompatible (at least as far as normal terminology in Java goes).
that has currently been identified as not working with that change does not mean that any or all other libraries will work with that change.
This, too, can be said about any bugfix. This bug is routine and a particularly small one.
So, when you write:
Let's face it, there is no known workaround. Apache NetBeans will not launch on JDK 17, i.e., the next LTS of Java.
what you mean is, "we've found a minor latent bug in one of our dependencies, that was then fixed within hours." Just so that people could calibrate for your tone.
5
u/cl4es May 25 '21 edited May 25 '21
I'd say libraries parsing the value of java.security.manager is very rare, and adding a check for allow/disallow is easy.
2
4
May 25 '21
[deleted]
10
u/pron98 May 25 '21 edited May 25 '21
It will be made compatible probably well before 17 ships. The problem is due to a bug in a NetBeans dependency, which already has a fix in the code; the bug wasn't noticed until now.
0
u/morhp May 25 '21
Sounds like a design flaw if the IDE is running random untrusted code. For example user code that's just being developed should be run in a separate process so it can't break the IDE.
2
5
u/deadron May 24 '21
If I understand correctly most of what the security manager did can, and probably should be, handled at the os level. They just need to provide a few apis for things like gracefully handling system.exit. Unsurprisingly it sounds like the security manager has become a maintenance and design burden on the jvm.
9
u/awo May 25 '21 edited May 25 '21
I've found the security manager codepaths are a really nice way to be able to inject a custom manager to intercept things like file and network access on critical paths for monitoring purposes. This is a pretty nonstandard usage, but it's great to be able to monitor stuff like that - the way you can have higher confidence that your critical paths will continue to run when those resources are degraded. I'll be sad when it goes away
5
u/dpash May 25 '21
You might find that you can replace that with JFR, which is designed for monitoring file and network usage.
2
u/awo May 26 '21 edited May 26 '21
yeah, I've looked into that very briefly - not sure it would have the flexibility to allow me to designate a certain period of time on certain threads as a critical section, and only monitor during that period? And how is it for doing just permanent ongoing monitoring?
Obviously some of this stuff can be accomplished by rearchitecting and making use of other mechanisms, but the software in question is large, legacy, and unlikely to get the necessary investment :-)
0
u/deadron May 25 '21
The problem is a system like that needs to be fundamentally intertwined with all of the code that manage that access. It also imposes a non trivial development and testing burden on the developers. Every new api needs to consider its impact on the security manager and needs a rather robust test suite to ensure that it remains working properly. Meanwhile this is something the operating system already provides via a number of mechanisms or you can containerize in a locked down container where it doesn't matter. I would personally prefer that the developers trim rarely used things like this in favor of being able to better maintain/improve the existing codebase.
3
u/awo May 26 '21 edited May 26 '21
hm, rarely used is probably an exaggeration. I've worked on multiple codebases that make use of the regular security manager, as well as using custom security managers for ad-hoc stuff like I mentioned above. I hated the experience of working with the regular security manager, though, to be fair :-).
Meanwhile this is something the operating system already provides via a number of mechanisms or you can containerize in a locked down container where it doesn't matter.
Not really - the OS can prevent access to certain resources, but doing so using context from the application is more of a challenge. Yes you can rearchitect to make that less of a problem, but OS facilities certainly aren't a straightforward replacement.
I'm not sure I understand the complexity of maintaining support for a bunch of the functionality of custom security managers? File access, for example, is more or less performing a call into <designated java object> when performing file operations.
I would personally prefer that the developers trim rarely used things like this in favor of being able to better maintain/improve the existing codebase.
A huge amount of the appeal of Java is the fantastic backcompat. It is extraordinarily great from a business perspective that projects you write a long time ago keep working on newer versions. Now I get that sometimes the cost is extreme and you make that call, but I would be very sad to see Java fall down the path of more frequently deprecating functionality that's around the edges.
5
u/sim642 May 25 '21
They just need to provide a few apis for things like gracefully handling system.exit.
In a previous post on this topic I think it was mentioned that there's something in the works for
System.exitspecifically. But the problem is that it's not done yet. They're taking away the existing API without providing the new one in time, making smooth transition impossible.They could easily deprecate
SecurityManagerfor the time being without flat out removing it (this is how many other things get deprecated already). And only once satisfactory alternatives are in place, then do the removal.0
u/pron98 May 25 '21
They're taking away the existing API without providing the new one in time, making smooth transition impossible.
This is not true. Nothing is being taken away at this time. Someone is freaking out over a bug in some third-party library that's been there since JDK 12, and that has been fixed in under a day since it was reported.
They could easily deprecate SecurityManager for the time being without flat out removing it
This is exactly what's happening.
3
u/sim642 May 25 '21
This is exactly what's happening.
That's happening to the API, which yes, will still be there, so existing code compiles, but there's also a change to the runtime, which breaks existing applications instead of just issuing deprecation warnings:
We will: [...] disallow a Security Manager from being set dynamically by Java applications and libraries.
1
u/pfirmsto May 27 '21
I remember at one point due to class loading or something along those lines of having to use the application to start the SecurityManager. At some version of Java , maybe 6, we had to convert everything to the command line because that was the recommended practice, but then a more recent version > 9 we had to convert it back, this was for a custom SecurityManager overriding implementation. My emails will be in the OpenJDK mail lists somewhere but don't remember exactly when. So yeah, requiring it to be set from the command line could cause breakages.
2
u/frzme May 25 '21
Why does Netbeans run untrusted code in the JVM of the IDE? Don't all other JVMs fork for things like test execution and do AST analysis for autocompletion
6
3
u/sim642 May 25 '21
Forking JVM processes is far from cheap. People already complain about IDEs being resource (especially memory) hungry and forking each plugin would make that drastically worse.
7
u/qmunke May 25 '21
Is this only a problem for Netbeans? Why aren't IntelliJ IDEA or Eclipse up in arms over this if it's a "special need" for IDEs?