Skip to content
This repository has been archived by the owner. It is now read-only.

8269543: The warning for System::setSecurityManager should only appear once for each caller #166

Closed
wants to merge 3 commits into from

Conversation

@wangweij
Copy link
Contributor

@wangweij wangweij commented Jun 28, 2021

Add a cache to record which sources have called System::setSecurityManager and only print out warning lines once for each.


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

  • JDK-8269543: The warning for System::setSecurityManager should only appear once for each caller

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk17 pull/166/head:pull/166
$ git checkout pull/166

Update a local copy of the PR:
$ git checkout pull/166
$ git pull https://git.openjdk.java.net/jdk17 pull/166/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 166

View PR using the GUI difftool:
$ git pr show -t 166

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk17/pull/166.diff

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Jun 28, 2021

👋 Welcome back weijun! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

Loading

@openjdk
Copy link

@openjdk openjdk bot commented Jun 28, 2021

@wangweij The following label will be automatically applied to this pull request:

  • core-libs

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

Loading

@openjdk openjdk bot added the core-libs label Jun 28, 2021
@wangweij wangweij marked this pull request as ready for review Jun 29, 2021
@openjdk openjdk bot added the rfr label Jun 29, 2021
@mlbridge
Copy link

@mlbridge mlbridge bot commented Jun 29, 2021

Webrevs

Loading

@wangweij
Copy link
Contributor Author

@wangweij wangweij commented Jun 29, 2021

/label add security

Loading

@openjdk openjdk bot added the security label Jun 29, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Jun 29, 2021

@wangweij
The security label was successfully added.

Loading

final static Map<String, Boolean> callers
= Collections.synchronizedMap(new WeakHashMap<>());
}

Copy link
Member

@dfuch dfuch Jun 29, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder about the use of a WeakHashMap here. That may work well when the source is an interned string (a class name) which will be strongly referenced elsewhere and may be garbage collected if the class is unloaded, but in the case where it contains the name of the source jar then that string will only be referenced by the weak hashmap, and therefore it could be garbage collected any time - which would cause the mapping to be removed. In that case you cannot guarantee that the warning will be emitted only once.

Loading

Copy link
Contributor

@RogerRiggs RogerRiggs Jun 29, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using a HashSet could use the callerClass as the key and be a stable reference for having given the message.
or use a ConcurrentHashMap<Class<?>>, boolean> and avoid any separate synchronization that would be needed with a HashSet or HashMap.

Loading

Copy link
Contributor Author

@wangweij wangweij Jun 29, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I switch to a "non-weak" set or map, then it seems I can safely use the source string as the key. Will using the Class object as a key prevent them from unloading?

Loading

Copy link
Contributor

@RogerRiggs RogerRiggs Jun 29, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using a synchronized WeakHashMap with the class as the key would not prevent class unloading.
Using a non-weak set or map to strings would keep the strings around for the life of the runtime.

Loading

Copy link
Contributor Author

@wangweij wangweij Jun 29, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hope this is uncommon but if that class is loaded by a ClassLoader again and again then it will be different each time. I'll investigate more.

Loading

Copy link
Contributor

@AlanBateman AlanBateman Jun 30, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WeakHashMap<Class<?>, Boolean>, where the key is the caller, should be okay (assume synchronization of course). Even with applications that do call setSecurityManager then the map is probably going to be one entry. I wouldn't expect it is common to create custom class loaders that load code that sets a security manager, meaning it is more likely that the container sets the SM rather have each plugin/application/whatever try to set the system-wide SM.

Loading

Copy link
Contributor Author

@wangweij wangweij Jun 30, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Switched to Class<?> as cache key. New commit pushed.

Loading

@mlbridge
Copy link

@mlbridge mlbridge bot commented Jun 29, 2021

Mailing list message from Chapman Flack on security-dev:

On 06/29/21 15:39, Weijun Wang wrote:

If I switch to a "non-weak" set or map, then it seems I can safely use
the source string as the key. Will using the Class object as a key prevent
them from unloading?

I understand that it's in principle possible for classes to get GC'd,
though I don't know how often it happens in typical practical settings.

This seems like a question to be approached from the angle of asking
what the wanted semantics should be. What should be the effect on warning
messages if class a.b.C is loaded and sets a security manager, and is later
GC'd, and then a class also named a.b.C is later loaded, and sets a security
manager?

It seems like a preferred answer to that question would determine
whether to make the set weak or not.

Regards,
-Chap

Loading

1 similar comment
@mlbridge
Copy link

@mlbridge mlbridge bot commented Jun 29, 2021

Mailing list message from Chapman Flack on security-dev:

On 06/29/21 15:39, Weijun Wang wrote:

If I switch to a "non-weak" set or map, then it seems I can safely use
the source string as the key. Will using the Class object as a key prevent
them from unloading?

I understand that it's in principle possible for classes to get GC'd,
though I don't know how often it happens in typical practical settings.

This seems like a question to be approached from the angle of asking
what the wanted semantics should be. What should be the effect on warning
messages if class a.b.C is loaded and sets a security manager, and is later
GC'd, and then a class also named a.b.C is later loaded, and sets a security
manager?

It seems like a preferred answer to that question would determine
whether to make the set weak or not.

Regards,
-Chap

Loading

@mlbridge
Copy link

@mlbridge mlbridge bot commented Jun 30, 2021

Mailing list message from Bernd Eckenfels on security-dev:

Hello, sorry for being unpopular, but I just hate it to waste developer resources,

I realy think this deprecation message should be re-considered, it broke a lot of things, the amount of work to implement a caching solution feels like a waste of time and on top of it, there is no clear replacement strategy published yet.

I would restrict deprication (for removal if you really insist) to javadoc and not poison stdout/stderr.

I think we stirred up enough PR that a message was received by maintainers, no need to further damage java reputation by breaking perfectly working inter process interfaces. (This is btw true for all such warnings). And I also think top priority should be to publish a go-forward route which should not depend solely on MR-Jars,

Gruss
Bernd

--
http://bernd.eckenfels.net
________________________________
Von: security-dev <security-dev-retn at openjdk.java.net> im Auftrag von Daniel Fuchs <dfuchs at openjdk.java.net>
Gesendet: Tuesday, June 29, 2021 8:50:08 PM
An: core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>; security-dev at openjdk.java.net <security-dev at openjdk.java.net>
Betreff: Re: [jdk17] RFR: 8269543: The warning for System::setSecurityManager should only appear once for each caller

On Mon, 28 Jun 2021 21:09:43 GMT, Weijun Wang <weijun at openjdk.org> wrote:

Add a cache to record which sources have called `System::setSecurityManager` and only print out warning lines once for each.

src/java.base/share/classes/java/lang/System.java line 337:

335: = Collections.synchronizedMap(new WeakHashMap<>());
336: }
337:

I wonder about the use of a WeakHashMap here. That may work well when the source is an interned string (a class name) which will be strongly referenced elsewhere and may be garbage collected if the class is unloaded, but in the case where it contains the name of the source jar then that string will only be referenced by the weak hashmap, and therefore it could be garbage collected any time - which would cause the mapping to be removed. In that case you cannot guarantee that the warning will be emitted only once.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/166
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20210630/48020b81/attachment.htm>

Loading

@mlbridge
Copy link

@mlbridge mlbridge bot commented Jun 30, 2021

Mailing list message from Alan Bateman on core-libs-dev:

On 30/06/2021 08:19, Bernd Eckenfels wrote:

Hello, sorry for being unpopular, but I just hate it to waste
developer resources,

I realy think this deprecation message should be re-considered, it
broke a lot of things, the amount of work to implement a caching
solution feels like a waste of time and on top of it, there is no
clear replacement strategy published yet.

I would restrict deprication (for removal if you really insist) to
javadoc and not poison stdout/stderr.

The purpose of the warning message is to make it very clear that
applications that call System.setSecurityManager in a running VM will
fail in the future. It is not hugely different to the "Illegal
reflective access" warning that were emitted in JDK 9 to JDK 15. Maybe
you could clarify what you mean by "it broke a lot of things". If you
have something that is sensitive to warnings going to stderr then I
would have expected the "Illegal reflective access" warnings to have
caused a lot more issues.

-Alan.

Loading

1 similar comment
@mlbridge
Copy link

@mlbridge mlbridge bot commented Jun 30, 2021

Mailing list message from Alan Bateman on core-libs-dev:

On 30/06/2021 08:19, Bernd Eckenfels wrote:

Hello, sorry for being unpopular, but I just hate it to waste
developer resources,

I realy think this deprecation message should be re-considered, it
broke a lot of things, the amount of work to implement a caching
solution feels like a waste of time and on top of it, there is no
clear replacement strategy published yet.

I would restrict deprication (for removal if you really insist) to
javadoc and not poison stdout/stderr.

The purpose of the warning message is to make it very clear that
applications that call System.setSecurityManager in a running VM will
fail in the future. It is not hugely different to the "Illegal
reflective access" warning that were emitted in JDK 9 to JDK 15. Maybe
you could clarify what you mean by "it broke a lot of things". If you
have something that is sensitive to warnings going to stderr then I
would have expected the "Illegal reflective access" warnings to have
caused a lot more issues.

-Alan.

Loading

@jaikiran
Copy link
Member

@jaikiran jaikiran commented Jun 30, 2021

FWIW - I built a local JDK with this PR and gave it a try against one of the original Apache Ant project example where the warnings were previously flooding the stderr. With this change, I now see the warning message just once (as expected) for that example.

Loading

@openjdk
Copy link

@openjdk openjdk bot commented Jul 1, 2021

@wangweij This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8269543: The warning for System::setSecurityManager should only appear once for each caller

Reviewed-by: lancea, alanb, dfuchs

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 53 new commits pushed to the master branch:

  • 2db9005: 8262017: C2: assert(n != __null) failed: Bad immediate dominator info.
  • 7bc96db: 8269771: assert(tmp == _callprojs.fallthrough_catchproj) failed: allocation control projection
  • 5644c4f: 8265132: C2 compilation fails with assert "missing precedence edge"
  • a4d2a9a: 8269745: [JVMCI] restore original qualified exports to Graal
  • e377397: 8268566: java/foreign/TestResourceScope.java timed out
  • 6c76e77: 8260684: vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java timed out
  • 4bbf11d: 8269580: assert(is_valid()) failed: invalid register (-1)
  • 54dd510: 8269704: Typo in j.t.Normalizer.normalize()
  • a8385fe: 8269354: javac crashes when processing parenthesized pattern in instanceof
  • c16d1fc: 8269285: Crash/miscompile in CallGenerator::for_method_handle_inline after JDK-8191998
  • ... and 43 more: https://git.openjdk.java.net/jdk17/compare/4eb321298a1abf6b24bd9515c5c0c3580b2f31f7...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

Loading

@openjdk openjdk bot added the ready label Jul 1, 2021
dfuch
dfuch approved these changes Jul 2, 2021
@wangweij
Copy link
Contributor Author

@wangweij wangweij commented Jul 2, 2021

/integrate

Loading

@openjdk
Copy link

@openjdk openjdk bot commented Jul 2, 2021

Going to push as commit c4ea13e.
Since your change was applied there have been 53 commits pushed to the master branch:

  • 2db9005: 8262017: C2: assert(n != __null) failed: Bad immediate dominator info.
  • 7bc96db: 8269771: assert(tmp == _callprojs.fallthrough_catchproj) failed: allocation control projection
  • 5644c4f: 8265132: C2 compilation fails with assert "missing precedence edge"
  • a4d2a9a: 8269745: [JVMCI] restore original qualified exports to Graal
  • e377397: 8268566: java/foreign/TestResourceScope.java timed out
  • 6c76e77: 8260684: vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java timed out
  • 4bbf11d: 8269580: assert(is_valid()) failed: invalid register (-1)
  • 54dd510: 8269704: Typo in j.t.Normalizer.normalize()
  • a8385fe: 8269354: javac crashes when processing parenthesized pattern in instanceof
  • c16d1fc: 8269285: Crash/miscompile in CallGenerator::for_method_handle_inline after JDK-8191998
  • ... and 43 more: https://git.openjdk.java.net/jdk17/compare/4eb321298a1abf6b24bd9515c5c0c3580b2f31f7...master

Your commit was automatically rebased without conflicts.

Loading

@openjdk openjdk bot closed this Jul 2, 2021
@openjdk openjdk bot added integrated and removed ready rfr labels Jul 2, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Jul 2, 2021

@wangweij Pushed as commit c4ea13e.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

Loading

@wangweij wangweij deleted the 8269543 branch Jul 2, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.