On Wed, May 12, 2021 at 10:22 PM Ron Pressler <ron.press...@oracle.com> wrote:
> > > > On 12 May 2021, at 21:46, Peter Tribble <peter.trib...@gmail.com> wrote: > > > > 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. > > Could you describe what your use-case is in the most precise way you can? > Let me give a concrete example: Parsing and rendering a PDF file that may contain references to fonts or other resources. We know exactly where the files are installed, so wish to allow the rendering routine access to the fonts it will need. But not to any other files, and not (normally) to network resources at all. Note that we trust the code, but not necessarily the document it's parsing. (Although the document itself may be perfectly well formed - document formats often allow embedding references to 3rd-party objects, undesirable as that may be.) There are a range of such issues in document parsing and rendering. And unfortunately, the good libraries for this task are proprietary so we can't modify them to apply the restrictions we're after. The (server-side) application does need access to files and network resources at other times; it's only when it goes into the rendering step that we lock it down, and unlock it once done. > That there are useful applications of the Security Manager out there is > certain; the same > was certainly also true for Applets. The problem is that the total good > that the Security > Manager contributes does not justify the high cost of its maintenance. The > more we can > understand what people use it for and how, the better we are able to judge > how much we > should afford to put into some simpler replacement. Having said that, it > is certainly > possible that some of the millions of Java developers out there will be > disappointed. We > try to direct our resources where they’d do the most good, and when we > can, try to find > a solution for small groups that are harmed by such budgeting. > I appreciate the reasoning here, and thanks for letting us try and describe some our use cases. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
