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

[Bernd Eckenfels]

Is it possible to redirect those vm messages with unified logging or vm-error files or similar command line flags to the launcher to keep stdout/stderr clean?

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: security-dev <security-dev-retn at openjdk.java.net> im Auftrag von Sean Mullan <sean.mullan at oracle.com>
Gesendet: Monday, June 14, 2021 8:49:43 PM
An: Jaikiran Pai <jai.forums2013 at gmail.com>; security-dev at openjdk.java.net <security-dev at openjdk.java.net>
Betreff: Re: JDK 17 EA build 26 - Better debuggability of SecurityManager WARNING messages?

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210615/32236d1a/attachment.htm>