Elasticsearch: Stack overflow with security manager debugging

Created on 15 Apr 2019  路  8Comments  路  Source: elastic/elasticsearch

A stack overflow occurs when using the gradle test runner and passing security manager debugging sysprops. This used to work with randomized runner, and also still works when running junit directly from intellij.

Example command line:

./gradlew :server:test --tests "org.elasticsearch.cluster.coordination.CoordinatorTests.testCannotJoinClusterWithDifferentUUID" -Dtests.seed=2E7BBEA3C26E83E0 -Dtests.security.manager=true -Dtests.locale=sw -Dtests.timezone=America/Edmonton -Dcompiler.java=12 -Druntime.java=12 -Dtests.jvm.argline="-Djava.security.debug=access,failure"

:DeliverBuild >bug Delivery

Most helpful comment

I've raised a PR with a fix for this to the gradle codebase at https://github.com/gradle/gradle/pull/15634

All 8 comments

Pinging @elastic/es-core-infra

This is actually kind of hilarious. So the issue is that when Java goes to log the security access info, that gets delegated through all the Gradle logging infrastructure. Well, within that Gradle makes a call to System.getProperty("line.separator") in order to determine how to properly format the output, which triggers a security permission check, which is logged, which goes to lookup the line separator, which triggers a permission check.... and so on.

I'm looking to see if we can instead make this a static initialization thing in Gradle to get around this runtime problem.

I played around with this just a little bit and there's no simple solution here unfortunately. I'll keep having a think about this though.

The test runner should have permissions for all sysprops. Perhaps there is a missing doPriv around the property getting?

Right, but logging "access" includes when a permission check is allowed. If you are just looking for instances where the security manager denies a particular permission just use "failure". That works just fine.

I don't think we should be restricted to not using access, as it is sometimes useful.

I don't disagree. We'll keep this issue open and revisit it.

I've raised a PR with a fix for this to the gradle codebase at https://github.com/gradle/gradle/pull/15634

Was this page helpful?
0 / 5 - 0 ratings