Re: Fwd: Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable
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 no-arg variant) should *always* have been a no-op. All it really accomplishes, in practice, is to place a mark on the stack where the stack crawl to build the access control context should stop (plus one frame), and this effect is something that is already a natural consequence of a method being called in the JVM. The doPrivileged variant that accepts an ACC parameter should likewise always have been no-op other than stashing the nested ACC into some sort of thread-local (or better, a field on Thread) which can be referred to by the aforementioned stack crawl. The pure-java AccessController I prototyped late last year relies on these ideas, among other things. -- - DML
Re: Fwd: Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable
On 10/3/18 8:52 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?
Yes, it may be possible, and we have prototyped it. But I didn't want to
mix it up with this one as it has some different specification
challenges -- for example, the AccessController APIs can be used
independently of the SecurityManager. I plan to get back to this one
soon and hope to have something that can be reviewed a bit later.
Thanks,
Sean
On 03/10/2018 13:12, Sean Mullan wrote:
For those of you that are not also subscribed to security-dev, this is
mostly FYI, as the review is winding down, but if you have any
comments, let me know.
This change will add new token options ("allow" and "disallow") to the
java.security.manager system property. The "disallow" option is
intended to provide a potential performance boost for applications
that don't enable a SecurityManager, as there is a cost associated
with allowing a SecurityManager to enabled at runtime, even if it is
never enabled. The 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
From: Sean Mullan
Organization: Oracle Corporation
To: security Dev OpenJDK
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:
http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.01/
The main changes since the initial revision are:
1. System.setSecurityManager is no longer deprecated. This type of
change clearly needs more discussion and is not an essential part of
this RFE.
2. After further thought, I took Bernd's suggestion [1] and instead of
adding a new property to disallow the setting of a SecurityManager at
runtime, have added new tokens to the existing "java.security.manager"
system property, named "=disallow", and "=allow" to toggle this
behavior. The "=" is to avoid any potential clashes with custom SM
classes with those names. I think this is a cleaner approach. There
are a couple of new paragraphs in the SecurityManager class
description describing the "java.security.manager" property and how
the new tokens work.
3. I also added a comment that Bernd had requested [2] on why
System.setSecurityManager calls checkPackageAccess("java.lang").
Also, the CSR has been updated:
https://bugs.openjdk.java.net/browse/JDK-8203316
Thanks,
Sean
[1]
http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018217.html
[2]
http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018193.html
On 9/13/18 4: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 performance overhead even for applications that never call it and
do not enable a SecurityManager dynamically, which is probably the
majority of applications.
For example, there are lots of "SecurityManager sm =
System.getSecurityManager(); if (sm != null) ..." checks in the JDK.
If it was known that a SecurityManager could never be set at
run-time, these checks could be optimized using constant-folding.
There are essentially two main parts to this change:
1. Deprecation of System.securityManager()
Going forward, we want to discourage applications from calling
System.setSecurityManager(). Instead they should enable a
SecurityManager using the java.security.manager system property on
the command-line.
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 known that an application will never
run with a SecurityManager. To support this behavior, the
System.setSecurityManager() API has been updated such that it can
throw an UnsupportedOperationException if it does not allow a
security manager to be set dynamically.
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
(I will likely also send this to core-libs for additional review later)
--Sean
Re: Fwd: Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable
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?
On 03/10/2018 13:12, Sean Mullan wrote:
For those of you that are not also subscribed to security-dev, this is
mostly FYI, as the review is winding down, but if you have any comments,
let me know.
This change will add new token options ("allow" and "disallow") to the
java.security.manager system property. The "disallow" option is intended
to provide a potential performance boost for applications that don't
enable a SecurityManager, as there is a cost associated with allowing a
SecurityManager to enabled at runtime, even if it is never enabled. The
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
From: Sean Mullan
Organization: Oracle Corporation
To: security Dev OpenJDK
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:
http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.01/
The main changes since the initial revision are:
1. System.setSecurityManager is no longer deprecated. This type of
change clearly needs more discussion and is not an essential part of
this RFE.
2. After further thought, I took Bernd's suggestion [1] and instead of
adding a new property to disallow the setting of a SecurityManager at
runtime, have added new tokens to the existing "java.security.manager"
system property, named "=disallow", and "=allow" to toggle this
behavior. The "=" is to avoid any potential clashes with custom SM
classes with those names. I think this is a cleaner approach. There are
a couple of new paragraphs in the SecurityManager class description
describing the "java.security.manager" property and how the new tokens
work.
3. I also added a comment that Bernd had requested [2] on why
System.setSecurityManager calls checkPackageAccess("java.lang").
Also, the CSR has been updated:
https://bugs.openjdk.java.net/browse/JDK-8203316
Thanks,
Sean
[1]
http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018217.html
[2]
http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018193.html
On 9/13/18 4: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 performance overhead even for applications that never call it and do
not enable a SecurityManager dynamically, which is probably the
majority of applications.
For example, there are lots of "SecurityManager sm =
System.getSecurityManager(); if (sm != null) ..." checks in the JDK.
If it was known that a SecurityManager could never be set at run-time,
these checks could be optimized using constant-folding.
There are essentially two main parts to this change:
1. Deprecation of System.securityManager()
Going forward, we want to discourage applications from calling
System.setSecurityManager(). Instead they should enable a
SecurityManager using the java.security.manager system property on the
command-line.
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 known that an application will never
run with a SecurityManager. To support this behavior, the
System.setSecurityManager() API has been updated such that it can
throw an UnsupportedOperationException if it does not allow a security
manager to be set dynamically.
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
(I will likely also send this to core-libs for additional review later)
--Sean
--
Best regards, Sergey.
Fwd: Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable
For those of you that are not also subscribed to security-dev, this is
mostly FYI, as the review is winding down, but if you have any comments,
let me know.
This change will add new token options ("allow" and "disallow") to the
java.security.manager system property. The "disallow" option is intended
to provide a potential performance boost for applications that don't
enable a SecurityManager, as there is a cost associated with allowing a
SecurityManager to enabled at runtime, even if it is never enabled. The
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
From: Sean Mullan
Organization: Oracle Corporation
To: security Dev OpenJDK
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:
http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.01/
The main changes since the initial revision are:
1. System.setSecurityManager is no longer deprecated. This type of
change clearly needs more discussion and is not an essential part of
this RFE.
2. After further thought, I took Bernd's suggestion [1] and instead of
adding a new property to disallow the setting of a SecurityManager at
runtime, have added new tokens to the existing "java.security.manager"
system property, named "=disallow", and "=allow" to toggle this
behavior. The "=" is to avoid any potential clashes with custom SM
classes with those names. I think this is a cleaner approach. There are
a couple of new paragraphs in the SecurityManager class description
describing the "java.security.manager" property and how the new tokens work.
3. I also added a comment that Bernd had requested [2] on why
System.setSecurityManager calls checkPackageAccess("java.lang").
Also, the CSR has been updated:
https://bugs.openjdk.java.net/browse/JDK-8203316
Thanks,
Sean
[1]
http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018217.html
[2]
http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018193.html
On 9/13/18 4: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
performance overhead even for applications that never call it and do not
enable a SecurityManager dynamically, which is probably the majority of
applications.
For example, there are lots of "SecurityManager sm =
System.getSecurityManager(); if (sm != null) ..." checks in the JDK. If
it was known that a SecurityManager could never be set at run-time,
these checks could be optimized using constant-folding.
There are essentially two main parts to this change:
1. Deprecation of System.securityManager()
Going forward, we want to discourage applications from calling
System.setSecurityManager(). Instead they should enable a
SecurityManager using the java.security.manager system property on the
command-line.
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 known that an application will never run with a
SecurityManager. To support this behavior, the
System.setSecurityManager() API has been updated such that it can throw
an UnsupportedOperationException if it does not allow a security manager
to be set dynamically.
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
(I will likely also send this to core-libs for additional review later)
--Sean
