<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"><<a href="mailto:jcacek@redhat.com" target="_blank">jcacek@redhat.com</a>></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's not about wanting that or not wanting it I think. It's about the question if you run code that you trust or not on your server. If you don'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'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'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'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's no need to put guards in place. Either you trust the code and use it, or you don't trust the code and then don't use it. As soon as someone would feel a need to put a guard in place, then it means the code isn'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 "users" in "to allow users/deployed-apps/3rd-party-libs": the permissions you mentioned are all *code level* permissions. Users aren'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>