JDK 17 EA build 26 - Better debuggability of SecurityManager WARNING messages?

[Sean Mullan]

We already are working on improvements to the warning message to show 
the class and the source of the code calling System::setSecurityManager. 
See https://bugs.openjdk.java.net/browse/JDK-8268392

If that is not sufficient and a stack trace is really still needed, my 
preference would be to leverage the existing java.security.debug system 
property, and add a new value, say "sm" and that would additionally 
print a stack trace. But let's see if this is really needed first.

--Sean

On 6/14/21 12:59 PM, Jaikiran Pai wrote:
> While testing the Apache Ant project with the latest released EA of JDK
> 17[1] (build 26), at least one of our internal test case has started
> failing. The failure relates to the new "WARNING" message that gets
> printed out to System.err when some code at runtime sets the security
> manager. The test case we have expects that the System.err stream
> contains only specific content. However, with this change, it now finds
> the expected content plus this additional warning message:
> 
> WARNING: java.lang.System::setSecurityManager is deprecated and will be
> removed in a future release.
> 
> Given the way the test is written, it doesn't like the presence of this
> additional content on System.err and fails.
> 
> "Fixing" this test itself is pretty trivial for us and given that it's
> just one such test, I plan to just go ahead and do that tomorrow.
> However, what I'm more interested in is what part of the code at runtime
> is setting the security manager. I think even that part I can probably
> easily narrow it down tomorrow once I look into the code. But from what
> I imagine, this is going to be much more difficult to narrow down if the
> security manager is being set at runtime from third party library code,
> deep in the ecosystem of the deployed application (imagine some code
> embedding Ant project and invoking it from their project).
> 
> I understand that the -Djava.security.manager system property allows the
> values "allow" and "disallow", but additionally would it be possible to
> introduce a new (optional) system property which takes a value "debug"?
> When this system property is set to "debug" and the Java runtime detects
> that a WARNING needs to be issued because of runtime setting of security
> manager, then a stacktrace is dumped showing the call location of each
> such code which is setting the security manager? This would be similar
> to the --illegal-access flag (although not a system property) that had
> the "debug" option, which I thought proved to be very useful when
> narrowing down the reflective access calls.
> 
> 
> [1] https://jdk.java.net/17/
> 
> -Jaikiran
> 
>