On 05/10/2018 18:52, dean.l...@oracle.com wrote:
Isn't this an implementation detail that could change? Could it say
instead "system class loader or one of its ancestors" or something
equally flexible?
I don't think there is much flexibility here. If the custom security
manager class
On 10/5/18 6:34 AM, Alan Bateman wrote:
On 05/10/2018 13:59, Sean Mullan wrote:
On 10/5/18 6:40 AM, Alan Bateman wrote:
The only issue I see is the statement "The class is loaded by the
system class loader ..." as it's actually the built-in application
class loader.
Is the "built-in
On 05/10/2018 13:59, Sean Mullan wrote:
On 10/5/18 6:40 AM, Alan Bateman wrote:
The only issue I see is the statement "The class is loaded by the
system class loader ..." as it's actually the built-in application
class loader.
Is the "built-in application class loader" something that is
On 10/5/18 6:40 AM, Alan Bateman wrote:
The only issue I see is the statement "The class is loaded by the system
class loader ..." as it's actually the built-in application class loader.
Is the "built-in application class loader" something that is specified
somewhere else? I'd like to link to
On 04/10/2018 22:04, Sean Mullan wrote:
Excellent comments, Stuart. Thanks for taking the time to review this.
I have posted another review that should address most of your
comments, but also responded inline with replies below.
http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.02/
Hi Sean,
Thanks for the updates. Looks like the details are all there now. One minor
point:
87 * If a class name is specified, it must be {@code
java.lang.SecurityManager}
88 * or a public subclass and have a public no-arg constructor. The class is
89 * loaded by the {@linkplain
Excellent comments, Stuart. Thanks for taking the time to review this.
I have posted another review that should address most of your comments,
but also responded inline with replies below.
http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.02/
I also posted the javadoc so you can see
On Wed, Oct 3, 2018 at 7:53 PM Sergey Bylokhov
wrote:
> Hi, Sean.
> One question related to SecurityManager and performance, is it possible
> to provide a special version of AccessController.doPrivileged which will
> be noop if SecurityManager is not present?
TBH that method (at least, the
he CSR provides a good summary of the issue and spec
changes: https://bugs.openjdk.java.net/browse/JDK-8203316
Thanks,
Sean
Forwarded Message ----
Subject: Re: RFR (12): 8191053: Provide a mechanism to make system's
security manager immutable
Date: Tue, 2 Oct 2018 11:34:09 -0400
F
wse/JDK-8203316
Thanks,
Sean
Forwarded Message ----
Subject: Re: RFR (12): 8191053: Provide a mechanism to make system's
security manager immutable
Date: Tue, 2 Oct 2018 11:34:09 -0400
From: Sean Mullan
Organization: Oracle Corporation
To: security Dev OpenJDK
Hello,
Than
Hi Sean,
The new arrangement of using special tokens for java.security.manager makes a
lot more sense than having a separate property. Overall, the proposed semantics
seem reasonable to me.
I have some suggestions to clarify the proposed specification. (But also see
below.) From webrev.01:
issue and spec changes:
https://bugs.openjdk.java.net/browse/JDK-8203316
Thanks,
Sean
Forwarded Message ----
Subject: Re: RFR (12): 8191053: Provide a mechanism to make system's
security manager immutable
Date: Tue, 2 Oct 2018 11:34:09 -0400
From: Sean Mullan
Organization: Oracle Corpor
On 10/2/18 2:47 PM, Alan Bateman wrote:
On 02/10/2018 16:34, Sean Mullan wrote:
Hello,
Thanks for all the comments so far, and the interesting discussions
about the future of the SecurityManager. We will definitely return to
those discussions in the near future, but for now I have a second
On 02/10/2018 16:34, Sean Mullan wrote:
Hello,
Thanks for all the comments so far, and the interesting discussions
about the future of the SecurityManager. We will definitely return to
those discussions in the near future, but for now I have a second
webrev ready for review for this
On 10/2/18 10:14 AM, Sean Mullan wrote:
On 10/2/18 1:05 PM, Mandy Chung wrote:
I'm not a fan of using double == which is not obvious to catch the
typo. I think the `==` syntax may not be commonly known either (I
suspect it's seldom for a user to override java.security.policy
rather than
On 10/2/18 1:05 PM, Mandy Chung wrote:
I'm not a fan of using double == which is not obvious to catch the
typo. I think the `==` syntax may not be commonly known either (I
suspect it's seldom for a user to override java.security.policy rather
than augmenting it).
Have you considered using
On 10/2/18 8:34 AM, Sean Mullan wrote:
Hello,
Thanks for all the comments so far, and the interesting discussions
about the future of the SecurityManager. We will definitely return to
those discussions in the near future, but for now I have a second
webrev ready for review for this
Hello,
Thanks for all the comments so far, and the interesting discussions
about the future of the SecurityManager. We will definitely return to
those discussions in the near future, but for now I have a second webrev
ready for review for this enhancement:
On 18/09/2018 15:07, Peter wrote:
Hi Alan,
I'm a little time poor presently, but will put it on my todo list.
Admittedly this is one part of the JVM that could have better test
coverage. Implementing a custom SecurityManager was fraught with
recursion difficulties,
If you can get time to
On 9/14/18 9:28 AM, David Lloyd wrote:
The security manager is legacy these days and I think we need to figure
out a plan how to deprecate and eventually bury it. I have no idea how
many releases or years that might take but the proposal here is a
profitable first step. It's easy to imagine
On 9/14/18 1:17 PM, Roger Riggs wrote:
Hi Sean,
Looks good.
I would quibble with System.java:335-6
"Java virtual machine does not allow a security manager"
I would say only "a security manager is not allowed to be set dynamically."
There is no need to identify the Java virtual machine.
On 2018-09-16 07:05, David Black wrote:
On 14 September 2018 at 13:46, David Lloyd wrote:
On Thu, Sep 13, 2018 at 3:03 PM Sean Mullan wrote:
This is a SecurityManager related change which warrants some additional
details for its motivation.
The current System.setSecurityManager() API
Hi Alan,
I'm a little time poor presently, but will put it on my todo list.
Admittedly this is one part of the JVM that could have better test
coverage. Implementing a custom SecurityManager was fraught with
recursion difficulties, I documented the pitfalls in our code.
Anyone who's
On 17/09/2018 13:41, Peter Firmstone wrote:
Has the attached regression been fixed "Re:
-Djava.security.manager=problems for service provider"? I recently
changed all our code to use System.setSecurityManager(), because of
this regression, prior to that we used the command line option, it's
I'm talking about sandboxing from the perspective of object capability
patterns, where you can contain some actor inside a constrained classloader
context and only allow execution through proxies that may be revoked. The
JEE model, in theory, allows you to run several web applications without
Has the attached regression been fixed "Re:
-Djava.security.manager=problems for service provider"? I recently
changed all our code to use System.setSecurityManager(), because of this
regression, prior to that we used the command line option, it's going to
take some time to revert...
On Sun, Sep 16, 2018 at 2:38 PM Will Sargent wrote:
>
> > The security manager is legacy these days and I think we need to figure out
> > a plan how to deprecate and eventually bury it.
>
> I don't know of any research or papers that explicitly say that
> SecurityManager is "legacy". I did
On 16/09/2018 20:37, Will Sargent wrote:
> The security manager is legacy these days and I think we need to
figure out a plan how to deprecate and eventually bury it.
I don't know of any research or papers that explicitly say that
SecurityManager is "legacy". I did some research into this a
> The security manager is legacy these days and I think we need to
figure out a plan how to deprecate and eventually bury it.
I don't know of any research or papers that explicitly say that
SecurityManager is "legacy". I did some research into this a while ago,
and while SecurityManager has some
On 14 September 2018 at 15:22, Alan Bateman wrote:
> On 14/09/2018 13:46, David Lloyd wrote:
>>
>> :
>>>
>>> There are essentially two main parts to this change:
>>>
>>> 1. Deprecation of System.s[etS]ecurityManager()
>>
>> We (JBoss) use this method to configure some things at run time (like
>>
On 14 September 2018 at 13:46, David Lloyd wrote:
> On Thu, Sep 13, 2018 at 3:03 PM Sean Mullan wrote:
>>
>> This is a SecurityManager related change which warrants some additional
>> details for its motivation.
>>
>> The current System.setSecurityManager() API allows a SecurityManager to
>> be
On 9/14/18 2:54 PM, Bernd Eckenfels wrote:
There is another way, by reusing the existing security manager property
with a new keyword („default“ is already a well known value) one could
implement the stable suppression of the SM without actually needing a
new property. It also avoids unclear
On 9/14/18 12:23 PM, Stuart Marks wrote:
On 9/14/18 4:52 AM, Daniel Fuchs wrote:
The name "jdk.allowSecurityManager" is actually fine.
I was also confused at first because I believed the
property, if set to false, would just prevent someone
to call System::setSecurityManager at runtime,
Cc: security Dev OpenJDK
Betreff: Re: RFR (12): 8191053: Provide a mechanism to make system's security
manager immutable
On 9/14/18 4:52 AM, Daniel Fuchs wrote:
> The name "jdk.allowSecurityManager" is actually fine.
>
> I was also confused at first because I believed the
Hi Sean,
Looks good.
I would quibble with System.java:335-6
"Java virtual machine does not allow a security manager"
I would say only "a security manager is not allowed to be set dynamically."
There is no need to identify the Java virtual machine. The VM itself
has nothing to do with it.
): 8191053: Provide a mechanism to make system's
security manager immutable
This is a SecurityManager related change which warrants some additional
details for its motivation.
The current System.setSecurityManager() API allows a SecurityManager to
be set at run-time. However, because of this
On 14/09/2018 14:28, David Lloyd wrote:
:
I can say that this explanation would be more palatable by far if the
security manager as a whole could be deprecated all at once. I for
one would certainly be happy to remove support for it in the software
that I maintain (it's a considerable amount of
On 14/09/2018 13:46, David Lloyd wrote:
:
There are essentially two main parts to this change:
1. Deprecation of System.s[etS]ecurityManager()
We (JBoss) use this method to configure some things at run time (like
customizing the Policy) before installing our security manager, so
this would be
On Thu, Sep 13, 2018 at 3:03 PM Sean Mullan wrote:
>
> This is a SecurityManager related change which warrants some additional
> details for its motivation.
>
> The current System.setSecurityManager() API allows a SecurityManager to
> be set at run-time. However, because of this mutability, it
On 14/09/2018 12:31, Daniel Fuchs wrote:
Maybe it would be less confusing if the property was named
-Djdk.disableSecurityManager, because AFAICT, it's what it does?
Forget I said that ;-)
The name "jdk.allowSecurityManager" is actually fine.
I was also confused at first because I believed
On 13/09/2018 21:02, Sean Mullan wrote:
:
webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.00/
CSR: https://bugs.openjdk.java.net/browse/JDK-8203316
JBS: https://bugs.openjdk.java.net/browse/JDK-8191053
This is inline with the discussion we had on this mailing list last year
On 14/09/2018 00:19, Bernd Eckenfels wrote:
:
I am curious, did you verify that the compiler will actually optimize
the getSecurityManager null check in case allow=never?
Yes, and the reason the allowSecurityManager field is an int rather than
a boolean is so that it get sets to a value
> On Sep 14, 2018, at 4:02 AM, Sean Mullan wrote:
>
> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.00/
public static SecurityManager getSecurityManager() {
+if (allowSecurityManager()) {
return security;
+} else {
+return null;
+
On 9/13/18 4:50 PM, Stuart Marks wrote:
Hi Sean,
Looks sensible to me.
On 9/13/18 1:02 PM, Sean Mullan wrote:
2. A new JDK-specific system property to disallow the setting of the
security manager at run-time: jdk.allowSecurityManager
If set to false, it allows the run-time to optimize the
On 9/13/18 1:02 PM, Sean Mullan wrote:
This is a SecurityManager related change which warrants some
additional details for its motivation.
The current System.setSecurityManager() API allows a SecurityManager
to be set at run-time. However, because of this mutability, it incurs
a
Hi Sean,
Looks sensible to me.
On 9/13/18 1:02 PM, Sean Mullan wrote:
2. A new JDK-specific system property to disallow the setting of the security
manager at run-time: jdk.allowSecurityManager
If set to false, it allows the run-time to optimize the code and improve
performance when it is
enfels.net
Von: -995614032m Auftrag von
Gesendet: Donnerstag, September 13, 2018 10:14 PM
An: security Dev OpenJDK
Betreff: RFR (12): 8191053: Provide a mechanism to make system's security
manager immutable
This is a SecurityManager related change which warrants some additional
detai
This is a SecurityManager related change which warrants some additional
details for its motivation.
The current System.setSecurityManager() API allows a SecurityManager to
be set at run-time. However, because of this mutability, it incurs a
performance overhead even for applications that
48 matches
Mail list logo
