Hi Andrew, > > I'm working on the assumption that OpenJDK will close any external holes > > currently defended by permission checks. It would be good if the JDK > > was secure by default, with properties required to be set for allowing > > such things as agents, management, parsing xml and serialization. > > You need to stop repeating this canard. There is no absolute need for > OpenJDK to retain a security mechanism to deal with problems that for > almost every use case are better solved by using non-OpenJDK > alternatives (such as OS security measures). Indeed, it's the other way > round: there is an imperative for the project to spend precious > resources on alternative capabilities (not necessarily security related).
Sorry, as another open source project affected by the stupid JEP 411 desaster I would like to fully confirm to EVERYTHING that Peter said. It is not a canard, it is the reality and I am really disappointed what happened. 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! So I will do the same: repeat the same story like Peter's over an over. Two large projects affected by your changes are Apache Solr and Elasticsearch. Both use security manager not only for security purposes, but also to control access to resources and classloading! Speed is also no issue if you use security manager correctly. In Apache Lucene/Solr/Elasticsearch there is NO slowdown visible as the hooks into security manager are only called for uncritical places (like opening a file before mmapping it, open a listening socket, loading a class...). The problem is: you deprecate for removal without offering any API to replace the main pain points: - preventing exit of JDK - an API to control class loading and prevent code from calling Method/Field/Constructor#setAccessible(true) for specific cases (e.g., you want a scripting language like Groovy to not allow caling sun.misc.Unsafe,...). Those things can never be done with code outside of the JVM! - Allow to hook into the I/O system. Unfortunately the java.nio FileSystem API is not enough: it does not cover java.io.File (why is this the case?) nor does the FileSystem API allows to hook in everywhere. We figured out that for example the new Panama interface to get a MemorySegment from a file path is not calling any API in the Filesystem abstraction! - Disable damn java serialization completely > The fact that your software can no longer profit from this specific > mechanism is a /special case/ which means any loss incurred is a > /special loss/ not a general one. Users who rely on your software for > the security guarantees you claim it provides may well no longer be able > to do so once this mechanism is removed. However, claiming that this > implies Java is no longer secure by default is a /gross/ > misrepresentation of what is at stake. The name "SecurityManager" is a legacy name. In fact "AccessController" and "Policy" is much better and exactly suits our needs and what we expect from it. We don't want security, we want access control and corresponding policies. That 2 different things! > Java can be used perfectly well to implement secure applications without > the security manager. That's evidenced by two facts: on the one hand > experience has shown that most programs that rely on the security > manager are not actually more secure because of using it; on the other > hand there are many highly secure Java programs out there in the field. That might be true, but the current state does not allow this for all use cases. Most projects use Security Manager not for security. Look at the code out there! > The fact that your software will no longer provide a specific route to > implementing a certain type of security capability may be a great loss > to you but it is not a significant loss, never mind some absolute loss > in kind, to Java and Java application developers. I recommend you stop > repeating this distorted opinion. It's only effect will be squander the > goodwill of those currently trying to help you, people whose driving > interest is nothing other than to make OpenJDK a better product. It is a great loss for many people, not only Peter. In Apache Lucene, Solr and Elastisearch, usage of SecurityManager will stay alive as long as possible (possible till Java version 27 or later). If it won't work anymore without a replacement to address the above painpoints Please revert the deprecation of SecurityManager and possibly delay the release of Java 17. In Java 18 work on new APIs like proposed in the JEP and then in Java 19 you can do a second try to deprecate/remove SecurityManager. Deprecating something without a proper replacement for the pain point is a bad idea. We have seen this in Java 9 already: Suddenly the module system was weakened shortly before release: because there was no replacement for sun.misc.Unsafe. Kind regards, Uwe
