On Thu, May 6, 2021 at 12:48 PM Alan Bateman <alan.bate...@oracle.com> wrote:
> On 06/05/2021 11:26, Peter Firmstone wrote: > > > > OpenJDK seems to have assumed that no one was using SecurityManager > > based on one research report. > > > I don't think this is right. Instead I would say that many of us have > rarely encountered deployments on the server-side that are using a > SecurityManager to enforce security as envisaged by the Java security > model. I've been at Java conferences where the sessions on this topic > had less than 10 people in the room. Most of the actual usages that I've > come across have been more like using the security manager as a > convenient way to intercept network and file access for the purposes of > logging or blocking. These usages may not have a need for protection > domains, stack walks, policy files and the other complexity that comes > with the security model. > We're (partly, at least) in that group. We can't block the access from outside the JVM (and we are containerized with restricted permissions already) because some accesses are legitimate - something outside the JVM doesn't know when the JVM is executing a particular piece of code, so we toggle the Security Manager on and off depending on context. And here's the thing; there isn't really anything in the proposal that addresses this use case, or offers an alternate way forward. > One thing that is missing from the discussions here is the cost and tax > that supporting the SM "operating mode" brings. Many of the big features > and all changes to security sensitive code must pay this tax. If there > is a bug, a missing checkPermission for example, then it gets treated as > security vulnerability at massive cost. Everything asynchronous brings > more complexity and effort to figure out where the checks should be and > whether an AccessControlContext needs to be carried around. I look > forward to the day where we can be like other languages and runtimes > that don't have to be concerned with this complexity and optional way of > running. > > Finally, just to point out again that this JEP is about deprecating for > removal in the future, it doesn't propose to remove the security manager > now. If it moves forward then it will probably be several releases of > degradation before it is removed. That gives time to properly consider > the use cases where the security manager is useful today. Also if it is > eventually removed, then anyone that really depends on this world can > continue to use supported releases for years to come. > I appreciate that there will be older versions we can run; the issue is always that there may be some external driver why we have to update - either to gain a critical feature, or because something else doesn't support the old version. I know I would feel a lot happier with this proposal and its implications if the consideration of those use cases where the security manager is useful today was more fully fleshed out. Thanks, -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
