<div dir="ltr">Hi,<br><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 23, 2014 at 2:40 PM, Josef Cacek <span dir="ltr">&lt;<a href="mailto:jcacek@redhat.com" target="_blank">jcacek@redhat.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">let me give you few examples. Do you really want to allow users/deployed-apps/3rd-party-libs<br>
<br>
 * call System.exit()?<br>
 * change behavior of the whole JVM by changing some system properties (keystores and truststores for instance)?<br>
 * use reflection to read/change private data (caches, etc)?<br>
 * access the filesystem (e.g. rewrite the WildFly configuration files)?<br>
 * ...<br></blockquote><div><br></div><div>It&#39;s not about wanting that or not wanting it I think. It&#39;s about the question if you run code that you trust or not on your server. If you don&#39;t trust your code, then you may indeed be tempted to put up guards against calling System.exit(), etc.<br>
<br></div><div>But...<br><br></div><div>In practice, in at least my experience, it just doesn&#39;t happen a lot if ever that you run untrusted code on a server.<br><br></div><div>In the majority of the cases the code I and my team deploy is the code that I and my team have written. We don&#39;t need to protect ourselves against calling System.exit(). If we suspect that a library that we use would be potentially malicious enough that it called System.exit() or did other nasty things then we just don&#39;t use it.<br>
<br></div><div>Since in the overwhelming majority of cases you totally control the code and all its dependencies on the server, there&#39;s no need to put guards in place. Either you trust the code and use it, or you don&#39;t trust the code and then don&#39;t use it. As soon as someone would feel a need to put a guard in place, then it means the code isn&#39;t fully trusted and thus the decision not to use that code has already been made IMHO.<br>
<br></div><div>And particularly about the &quot;users&quot; in &quot;to allow users/deployed-apps/3rd-party-libs&quot;: the permissions you mentioned are all *code level* permissions. Users aren&#39;t code, but interact with your system via its UI. So naturally you need a lot of user level permissions, but this is something else than code level ones.<br>
<br></div><div>Kind regards,<br>Arjan<br></div><div><br></div><div><br> </div></div></div></div></div>