Re: SecurityManager environments

On 28/04/2017 19:33, Russell Gold wrote: : This only works for executable jars? Not libraries? That is correct. If the executable JAR has Class-Path attributes then whoever is creating the application needs to have a global understanding so that the Add-Exports or Add-Opens has the complete

Re: SecurityManager environments

> On Apr 6, 2017, at 3:50 AM, Alan Bateman wrote: > The Add-Exports and Add-Opens attributes are the executable JAR equivalent of > the --add-exports and --add-opens command line options. So if an application > is hacking into say sun.awt then the maintainer of the

Re: SecurityManager environments

On 09/04/2017 23:15, Robert Muir wrote: I dont agree with the use of the word ephemeral here, thats misleading. Those permissions are *not* needed for outgoing connections. The default security policy of java absolutely allows for backdoors in server applications. It does not matter if port

Re: SecurityManager environments

I dont agree with the use of the word ephemeral here, thats misleading. Those permissions are *not* needed for outgoing connections. The default security policy of java absolutely allows for backdoors in server applications. It does not matter if port number is 80 or 8000 the effect is the same.

Re: SecurityManager environments

On 07/04/2017 03:54, Robert Muir wrote: : Because of these problems, if you are a server-side app, even if you understand this stuff and want to do the right thing, its really hard to avoid simply granting all kinds of horrible permissions globally to all code. In my experience the worst

Re: SecurityManager environments

: Reto Merz [mailto:reto.m...@abacus.ch] Sent: Thursday, April 6, 2017 6:53 PM To: Uwe Schindler <uschind...@apache.org>; 'Alan Bateman' < alan.bate...@oracle.com> Cc: jigsaw-dev@openjdk.java.net Subject: Re: SecurityManager environments We use the same approach like Elasticsearch (walk t

RE: SecurityManager environments

: Reto Merz [mailto:reto.m...@abacus.ch] Sent: Thursday, April 6, 2017 6:53 PM To: Uwe Schindler <uschind...@apache.org>; 'Alan Bateman' <alan.bate...@oracle.com> Cc: jigsaw-dev@openjdk.java.net Subject: Re: SecurityManager environments We use the same approach like Elasticsearch (

Re: SecurityManager environments

nyway. Regards Reto Von: Uwe Schindler <uschind...@apache.org> An: 'Alan Bateman' <alan.bate...@oracle.com>, 'Reto Merz' <reto.m...@abacus.ch> Kopie: <jigsaw-dev@openjdk.java.net> Gesendet: 06.04.2017 16:25 Betreff: RE: SecurityManager environment

Re: SecurityManager environments

I would agree with the paper that you shared, Dalibor. The SecurityManager system is not self-explanatory and I would also agree that, at least in the systems I worked with, there normally is no SecurityManager set, or even worse, the software fails with a SecurityManager set because some

RE: SecurityManager environments

Hi, > > >> To be honest, we don't see a lot of security manager > > >> usage on the server side these days. > > > > I'm really surprised about that. How can a app server or servlet container > > like JBoss Tomcat etc guarantee that System.exit does not shut down > > the JVM? > AFAIK the app

Re: SecurityManager environments

On 06.04.2017 15:24, Gregg Wonderly wrote: SecurityManager needs to be used more Potentially relevant academic research: http://www.cs.cmu.edu/~clegoues/docs/coker15acsac.pdf "We observed evidence that many developers struggle to understand and use the security manager for any purpose. This

Re: SecurityManager environments

> > On Apr 6, 2017, at 2:07 AM, Alan Bateman wrote: > > On 05/04/2017 20:53, Reto Merz wrote: > To be honest, we don't see a lot of security manager usage on the server side these days. >> >> I'm really surprised about that. How can a app server or servlet

Re: SecurityManager environments

On 05/04/2017 21:23, Gregg Wonderly wrote: Desktop applications started from a double clicked jar file, have no explicit access to the command line. It just doesn’t exist for that application. It only exists for “all” applications (launched for mime-type mapped application mappings) in

Re: SecurityManager environments

On 05/04/2017 20:53, Reto Merz wrote: >> To be honest, we don't see a lot of security manager >> usage on the server side these days. I'm really surprised about that. How can a app server or servlet container like JBoss Tomcat etc guarantee that System.exit does not shut down the JVM? AFAIK

Re: SecurityManager environments

> As regards the security manager then it's hard to see how it fits into the discussion. To be honest, we don't see a lot of security manager usage on the server side these days. I look at a lot of bug reports and error logs that include the command line and I don't see -Djava.security.manager

Re: SecurityManager environments

> On Apr 5, 2017, at 12:53 PM, Alan Bateman wrote: > > On 05/04/2017 16:26, Gregg Wonderly wrote: >> : >> At the forefront of the failure of the SecurityManager to be an avidly used >> element of Java applications, is the simple fact that the whole >> infrastructure

Re: SecurityManager environments

ion Of course there are still holes but in our case we just want to find erroneous code from new programmer colleague which is still a little green. Regards Reto Von: Alan Bateman <alan.bate...@oracle.com> An: Gregg Wonderly <gregg...@cox.net> Kopie: <jigsaw-dev@openjd

Re: SecurityManager environments

On 05/04/2017 16:26, Gregg Wonderly wrote: : At the forefront of the failure of the SecurityManager to be an avidly used element of Java applications, is the simple fact that the whole infrastructure is horribly inefficient and full of locks and mutable data which should not be locked and