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 l
> 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 application can shield
> the
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 n
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.
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 proble
>
> 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.mana
eto.m...@abacus.ch]
Sent: Thursday, April 6, 2017 6:53 PM
To: Uwe Schindler ; 'Alan Bateman' <
alan.bate...@oracle.com>
Cc: jigsaw-dev@openjdk.java.net
Subject: Re: SecurityManager environments
We use the same approach like Elasticsearch (walk through stack trace and
check caller).
No
: Reto Merz [mailto:reto.m...@abacus.ch]
Sent: Thursday, April 6, 2017 6:53 PM
To: Uwe Schindler ; 'Alan Bateman'
Cc: jigsaw-dev@openjdk.java.net
Subject: Re: SecurityManager environments
We use the same approach like Elasticsearch (walk through stack trace and check
caller).
Note that
nyway.
Regards
Reto
Von: Uwe Schindler
An: 'Alan Bateman' , 'Reto Merz'
Kopie:
Gesendet: 06.04.2017 16:25
Betreff: RE: SecurityManager environments
Hi,
> > >> To be honest, we don't see a lot of security manager
> > >>
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 librar
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 server
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
>
> 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 container
>> like JBoss Tom
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 most
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 th
> 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 very
> 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 is horribly inefficient and
security exception
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
An: Gregg Wonderly
Kopie:
Gesendet: 05.04.2017 19:53
Betreff: Re: SecurityM
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 shou
19 matches
Mail list logo
