Skip to content
This repository has been archived by the owner on Sep 2, 2022. It is now read-only.
/ jdk17 Public archive

8268349: Provide clear run-time warnings about Security Manager deprecation #13

Closed
wants to merge 7 commits into from

Conversation

wangweij
Copy link
Contributor

@wangweij wangweij commented Jun 11, 2021

More loudly and precise warning messages when a security manager is either enabled at startup or installed at runtime.

This is new PR for the openjdk/jdk17 repo copied from openjdk/jdk#4400. A new commit is added.


Progress

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

Issue

  • JDK-8268349: Provide clear run-time warnings about Security Manager deprecation ⚠️ Issue is not open.

Reviewers

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 13

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

Using diff file

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

@bridgekeeper
Copy link

bridgekeeper bot commented Jun 11, 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.

@wangweij
Copy link
Contributor Author

/label add security
/csr needed

@openjdk openjdk bot added rfr Pull request is ready for review security security-dev@openjdk.java.net labels Jun 11, 2021
@openjdk
Copy link

openjdk bot commented Jun 11, 2021

@wangweij
The security label was successfully added.

@openjdk openjdk bot added the csr Pull request needs approved CSR before integration label Jun 11, 2021
@openjdk
Copy link

openjdk bot commented Jun 11, 2021

@wangweij this pull request will not be integrated until the CSR request JDK-8268392 for issue JDK-8268349 has been approved.

@mlbridge
Copy link

mlbridge bot commented Jun 11, 2021

Webrevs

@wangweij wangweij changed the title 8268349: Provide more detail in JEP 411 warning messages 8268349: Provide clear run-time warnings about Security Manager deprecation Jun 14, 2021
@@ -31,6 +31,8 @@
import jdk.test.lib.process.OutputAnalyzer;
import jdk.test.lib.process.ProcessTools;

import java.io.ByteArrayOutputStream;
import java.io.PrintStream;
import java.security.Permission;

public class SecurityManagerWarnings {
Copy link
Member

Choose a reason for hiding this comment

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

This should probably have 8268349 in the @bug line.

Copy link
Contributor Author

@wangweij wangweij Jun 17, 2021

Choose a reason for hiding this comment

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

Fixed in new commit.

@@ -87,7 +87,5 @@ public static void main(String[] args) throws Exception {
throw new Exception
("Test with custom non-bootclass SecurityManager failed");
}

System.setSecurityManager(null);
Copy link
Member

Choose a reason for hiding this comment

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

Why did this line need to be removed?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is where the setSecurityManager method is called again when a security manager has already been installed, and the getProtectionDomain permission is needed. While I can add the new permission into the policy file, my understanding is that this line was just a clean-up and the test was about implementation of ProtectionDomain::toString (esp the seeAllp method called by it) when debug is on.

Copy link
Member

Choose a reason for hiding this comment

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

Ok, thanks for the explanation. I think it should be ok to remove this line then.

Copy link
Contributor

@AlanBateman AlanBateman left a comment

Choose a reason for hiding this comment

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

Implementation changes/text is okay.

@@ -324,6 +326,16 @@ private static void checkIO() {
private static native void setOut0(PrintStream out);
private static native void setErr0(PrintStream err);

// Remember original System.err. setSecurityManager() warning goes here
private static volatile @Stable PrintStream originalErrStream = null;
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd probably use "initial" rather than "original" here but okay. You can drop setting it to null as that is its default value.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Will do. Thanks.

@wangweij
Copy link
Contributor Author

A new commit. Much more exact checking of various warning messages.

System.err.println("WARNING: java.lang.System::setSecurityManager" +
" is deprecated and will be removed in a future release.");
var caller = Reflection.getCallerClass();
String signature = caller.getName() + " (" + codeSource(caller) + ")";
Copy link
Member

Choose a reason for hiding this comment

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

Hello Weijun,

Given that the codeSource() method above is allowed to return null, there could be a case where the warning message printed would be something like:

WARNING: A terminally deprecated method in java.lang.System has been called
WARNING: System::setSecurityManager has been called by foo.bar.Hello (null)
WARNING: Please consider reporting this to the maintainers of foo.bar.Hello
WARNING: System::setSecurityManager will be removed in a future release

Would that be OK or do you think the presence of "(null)" be unnecessary and confusing? Maybe in such cases that line should just say "System::setSecurityManager has been called by foo.bar.Hello"?

Another minor nit - the variable is named signature which initially gave me an impression that it was the method signature of the caller code, but that isn't the case. Should this variable be renamed perhaps?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catches. Will fix it. Thanks.

@jaikiran
Copy link
Member

Hello Sean, Weijung,

From what I have known, the Java/JDK code has always taken extra precaution when it comes to printing out potentially sensitive details like IP addresses and paths to file, like jar files in the log messages or exception stacktraces. In fact, one of the annoying things about some of the error messages that the JarFile API throws is that it doesn't even print out the jar file name, let alone the full path of the jar file which ran into issues. At least that was the case, unless that has changed in recent times. Furthermore, as you will surely know, to print out these details there's an security property which needs to be explicitly enabled ("jdk.includeInExceptions") with the right values.

Given all that, do you think that we should be printing the jar file paths in this WARNING message by default? I read the linked CSR, but I didn't see why the location of the jar or the name of the jar would be useful in this warning message. As long as the caller class (and perhaps the caller method) is printed, I think that should be enough of a summary on what's triggering this warning.

@mlbridge
Copy link

mlbridge bot commented Jun 18, 2021

Mailing list message from Alan Bateman on security-dev:

On 18/06/2021 03:51, Jaikiran Pai wrote:

:
Given all that, do you think that we should be printing the jar file paths in this WARNING message by default? I read the linked CSR, but I didn't see why the location of the jar or the name of the jar would be useful in this warning message. As long as the caller class (and perhaps the caller method) is printed, I think that should be enough of a summary on what's triggering this warning.

It's not hugely different to the "Illegal reflective access" warnings
except I wouldn't expect many libraries to call setSecurityManager in a
running system. Instead, it tends to be the main application that
installs the SM at startup. However if code in a library were to call it
then it useful to identify where that code is.

-Alan.

@wangweij
Copy link
Contributor Author

/csr needed

@openjdk
Copy link

openjdk bot commented Jun 22, 2021

@wangweij an approved CSR request is already required for this pull request.

@wangweij
Copy link
Contributor Author

/integrate

@openjdk
Copy link

openjdk bot commented Jun 22, 2021

@wangweij This PR has not yet been marked as ready for integration.

@wangweij
Copy link
Contributor Author

/csr unneeded

@wangweij
Copy link
Contributor Author

/integrate

@openjdk openjdk bot removed the csr Pull request needs approved CSR before integration label Jun 22, 2021
@openjdk
Copy link

openjdk bot commented Jun 22, 2021

@wangweij determined that a CSR request is not needed for this pull request.

@openjdk
Copy link

openjdk bot commented Jun 22, 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:

8268349: Provide clear run-time warnings about Security Manager deprecation

Reviewed-by: lancea, mullan, alanb

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 84 new commits pushed to the master branch:

  • 4099810: 8268293: VectorAPI cast operation on mask and shuffle is broken
  • e2d7ec3: 8267100: [BACKOUT] JDK-8196415 Disable SHA-1 Signed JARs
  • d3ad8cd: 8268672: C2: assert(!loop->is_member(u_loop)) failed: can be in outer loop or out of both loops only
  • f25e719: 8268717: Upstream: 8268673: Stack walk across optimized entry frame on fresh native thread fails
  • 22ebd19: 8268362: [REDO] C2 crash when compile negative Arrays.copyOf length after loop
  • f8df953: 8268702: JFR diagnostic commands lack argument descriptors when viewed using Platform MBean Server
  • c294ae4: 8267042: bug in monitor locking/unlocking on ARM32 C1 due to uninitialized BasicObjectLock::_displaced_header
  • b358b54: 8269063: Build failure due to VerifyReceiverTypes was not declared after JDK-8268405
  • b8f073b: 8268316: Typo in JFR jdk.Deserialization event
  • b9d7337: 8268638: semaphores of AsyncLogWriter may be broken when JVM is exiting.
  • ... and 74 more: https://git.openjdk.java.net/jdk17/compare/74007890bb9a3fa3a65683a3f480e399f2b1a0b6...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.

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Jun 22, 2021
@openjdk
Copy link

openjdk bot commented Jun 22, 2021

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

  • 4099810: 8268293: VectorAPI cast operation on mask and shuffle is broken
  • e2d7ec3: 8267100: [BACKOUT] JDK-8196415 Disable SHA-1 Signed JARs
  • d3ad8cd: 8268672: C2: assert(!loop->is_member(u_loop)) failed: can be in outer loop or out of both loops only
  • f25e719: 8268717: Upstream: 8268673: Stack walk across optimized entry frame on fresh native thread fails
  • 22ebd19: 8268362: [REDO] C2 crash when compile negative Arrays.copyOf length after loop
  • f8df953: 8268702: JFR diagnostic commands lack argument descriptors when viewed using Platform MBean Server
  • c294ae4: 8267042: bug in monitor locking/unlocking on ARM32 C1 due to uninitialized BasicObjectLock::_displaced_header
  • b358b54: 8269063: Build failure due to VerifyReceiverTypes was not declared after JDK-8268405
  • b8f073b: 8268316: Typo in JFR jdk.Deserialization event
  • b9d7337: 8268638: semaphores of AsyncLogWriter may be broken when JVM is exiting.
  • ... and 74 more: https://git.openjdk.java.net/jdk17/compare/74007890bb9a3fa3a65683a3f480e399f2b1a0b6...master

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot closed this Jun 22, 2021
@openjdk openjdk bot added integrated Pull request has been integrated and removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Jun 22, 2021
@openjdk
Copy link

openjdk bot commented Jun 22, 2021

@wangweij Pushed as commit ef4ba22.

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

@wangweij wangweij deleted the 8268349 branch June 22, 2021 02:16
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
integrated Pull request has been integrated security security-dev@openjdk.java.net
Development

Successfully merging this pull request may close these issues.

5 participants