<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 12, 2021 at 10:22 PM Ron Pressler <<a href="mailto:ron.pressler@oracle.com">ron.pressler@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On 12 May 2021, at 21:46, Peter Tribble <<a href="mailto:peter.tribble@gmail.com" target="_blank">peter.tribble@gmail.com</a>> wrote:<br>
> <br>
> We're (partly, at least) in that group. We can't block the access from outside<br>
> the JVM (and we are containerized with restricted permissions already) because<br>
> some accesses are legitimate - something outside the JVM doesn't know when<br>
> the JVM is executing a particular piece of code, so we toggle the Security Manager<br>
> on and off depending on context.<br>
> <br>
> And here's the thing; there isn't really anything in the proposal that addresses this<br>
> use case, or offers an alternate way forward.<br>
<br>
Could you describe what your use-case is in the most precise way you can?<br></blockquote><div><br></div><div>Let me give a concrete example:<br><br></div><div>Parsing and rendering a PDF file that may contain references to fonts or other resources.<br></div><div>We know exactly where the files are installed, so wish to allow the rendering routine access<br>to the fonts it will need. But not to any other files, and not (normally) to network resources at<br>all. Note that we trust the code, but not necessarily the document it's parsing. (Although the<br>document itself may be perfectly well formed - document formats often allow embedding<br></div><div>references to 3rd-party objects, undesirable as that may be.)<br></div><div><br></div><div>There are a range of such issues in document parsing and rendering. And unfortunately, the<br></div><div>good libraries for this task are proprietary so we can't modify them to apply the restrictions<br></div><div>we're after. The (server-side) application does need access to files and network resources at<br>other times; it's only when it goes into the rendering step that we lock it down, and unlock it<br>once done.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
That there are useful applications of the Security Manager out there is certain; the same<br>
was certainly also true for Applets. The problem is that the total good that the Security<br>
Manager contributes does not justify the high cost of its maintenance. The more we can<br>
understand what people use it for and how, the better we are able to judge how much we<br>
should afford to put into some simpler replacement. Having said that, it is certainly <br>
possible that some of the millions of Java developers out there will be disappointed. We<br>
try to direct our resources where they’d do the most good, and when we can, try to find<br>
a solution for small groups that are harmed by such budgeting.<br></blockquote><div><br></div><div>I appreciate the reasoning here, and thanks for letting us try and describe some our<br></div><div>use cases. <br></div></div><br>-- <br><div dir="ltr" class="gmail_signature">-Peter Tribble<br><a href="http://www.petertribble.co.uk/" target="_blank">http://www.petertribble.co.uk/</a> - <a href="http://ptribble.blogspot.com/" target="_blank">http://ptribble.blogspot.com/</a></div></div>