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-r...@openjdk.java.net> im Auftrag von Sean Mullan <sean.mul...@oracle.com> Gesendet: Monday, June 14, 2021 8:49:43 PM An: Jaikiran Pai <jai.forums2...@gmail.com>; security-dev@openjdk.java.net <security-dev@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 > >
