<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 22 Apr 2021, at 18:27, Reinier Zwitserloot <<a href="mailto:reinier@zwitserloot.com" class="">reinier@zwitserloot.com</a>> wrote:</div>
<div class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div class=""><br class="">
</div>
<div class="">For example, I may want to restrict access to the 'logs' directory. I can't restrict it at the OS level (because the JVM does need to write the log files, of course), at best I can restrict it at the module / package / code line level, allowing
the log framework write-only access, and deny it everywhere else.</div>
<div class=""><br class="">
</div>
<div class="">The problem at hand ("I want to treat my log dir as unreadable and unwriteable to my own process, except for logging code, which should be allowed to write") cannot be address with a 'configure the library' solution, unless the java (new) files
API grows a whole bunch of methods to redefine such things, and/or to try to shove into a custom FileSystem implementation some code that does stack trace introspection to try to make this happen.... and that still doesn't address the `java.io.File` API.</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">
<div dir="ltr" class="gmail_signature"> --Reinier Zwitserloot<br class="">
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
<div class="">The problem is that this is not doable with the Security Manager, either, except in theory. That the</div>
<div class="">Security Manager can do this *in principle* (depending on correct use of doPrivileged) is not in dispute. </div>
<div class="">But experience over they years has shown that people, *in practice* aren’t able to get Security Manager </div>
<div class="">to do that correctly; all the SM does is get people to *think* they can do it </div>
<div class="">(see <a href="http://www.cs.cmu.edu/~clegoues/docs/coker15acsac.pdf" class="">http://www.cs.cmu.edu/~clegoues/docs/coker15acsac.pdf</a>).</div>
<div class=""><br class="">
</div>
<div class="">Such an approach to security based on a highly-flexible sandbox is, empirically, not secure regardless of how </div>
<div class="">much we’d like it to work; Security Manager was designed so elaborately, because back then, when the approach </div>
<div class="">was new, people believed it could work. But having gained a couple of decades’ worth of experience with </div>
<div class="">software security and various approaches to it, we now that, perhaps disappointingly, it just doesn’t work.</div>
<div class="">In fact, it is worse than just not working — it’s insecure while giving a false sense of security.</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">— Ron</div>
<div class=""><br class="">
</div>
</body>
</html>