JLM tests with security enabled fail on Windows

[Mesbah-Alam]

JLM tests with security enabled fail on Windows with :

Successfully processed 1 files; Failed processing 0 files
ERROR: File ownership cannot be applied on insecure file systems;
       there is no support for ACLs.
**FAILED** at step 2 (Re-assign ownership for jmxremote.password file). Expected return value=0 Actual=256 at T://setUp.pl line 73.
STF 19:34:42.184 - **FAILED** setup script failed. Expected return value=0 Actual=1

https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/475/tapResults/

[Mesbah-Alam]

There is a step in the tests that set the ownership of jmxremote.password file to 600 using chmod (an STF api for doing chmod) that doesn't seem to be working on Windows.

It fails in the re-assign step : https://github.com/AdoptOpenJDK/stf/blob/21a60ab0fecaf127142882aa37ffce1cf9438fa4/stf.core/src/stf.core/net/adoptopenjdk/stf/extensions/core/StfCoreExtension.java#L364

[lumpfish]

stf is simulating the unix "chmod 600 file" command by running the following commands:

1. icacls test_dir\tmp\jmxremote.password /inheritance:r
2. takeown /f test_dir\tmp\jmxremote.password
3. icacls test_dir\tmp\jmxremote.password /grant currentUser:(r,w)

When I run the test locally the "takeown" command fails with "Access is denied" unless the shell running the command is "Run as Administrator". The "icacls" commands run OK.
So a different error to the one reported on the AdoptOpenJDK test machine.

If command 2. is excluded the test passes - i.e. the access is restricted as required by the test successfully anyway.
If commands 2. and 3. are excluded, the tests fails with

CL1 stderr Exception in thread "main" java.lang.SecurityException: Authentication failed! Error: unable to load the password file: C:/stf_temp/20190508-130007-TestJlmRemoteClassAuth/tmp/jmxremote.password
CL1 stderr      at java.management/com.sun.jmx.remote.security.JMXPluggableAuthenticator.authenticationFailure(JMXPluggableAuthenticator.java:227)
CL1 stderr      at java.management/com.sun.jmx.remote.security.JMXPluggableAuthenticator.authenticate(JMXPluggableAuthenticator.java:204)
CL1 stderr      at jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap$AccessFileCheckerAuthenticator.authenticate(ConnectorBootstrap.java:231)
CL1 stderr      at java.management.rmi/javax.management.remote.rmi.RMIServerImpl.doNewClient(RMIServerImpl.java:231)
........

So it seems that the takeown command is not necessary.

[lumpfish]

I've tried running a test at AdoptOpenJDK from my fork with the "takeown" command removed, but the test target TestJlmRemoteClassAuth doesn't appear to be recognised: https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder-systemtest/167/console. @Mesbah-Alam - any suggestion as to how I can run the test via https://ci.adoptopenjdk.net ?

[lumpfish]

@Mesbah-Alam - I've created a fork of openjdk-tests and updated the playlist there to reinstate the test for testing at AdoptOpenJDK.

[Mesbah-Alam]

The test was actually excluded from Windows + OpenJ9. It looks like you've already run another Grinder with it included! https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder-systemtest/170/

[lumpfish]

Yes, as I said above, I updated the playlist in my private fork of openjdk-tests. Unfortunately my openjdk-systemtest branch is now incompatible with the other repositories as a result of merging the (remove top.xml) build changes - I'll need to rebase on the latest master.

[Mesbah-Alam]

Yes, please do.