Kernel32LibraryTests creates JNA proxy classes

[rmuir]

With the current tests policy in place, this hits SecurityException (e.g. http://build-us-00.elasticsearch.org/job/es_core_master_window-2012/1004/console).

Does the functionality or just the test need to create these proxies? Can we avoid it? Otherwise, we can add this permission, but it is a little bit strange that JNA for e.g. unix mlockall does not need to create proxies but on windows it does.

Caused by: java.security.AccessControlException: access denied ("java.lang.reflect.ReflectPermission" "newProxyInPackage.org.elasticsearch.common.jna")
1> java.security.AccessControlContext.checkPermission(AccessControlContext.java:457)
1> java.security.AccessController.checkPermission(AccessController.java:884)
1> java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
1> [...java.lang.reflect.*]
1> com.sun.jna.Native.loadLibrary(Native.java:415)
1> com.sun.jna.Native.loadLibrary(Native.java:391)
1> org.elasticsearch.common.jna.Kernel32Library.(Kernel32Library.java:50)
1> org.elasticsearch.common.jna.Kernel32Library.(Kernel32Library.java:36)
1> org.elasticsearch.common.jna.Kernel32Library$Holder.(Kernel32Library.java:45)
1> org.elasticsearch.common.jna.Kernel32Library.getInstance(Kernel32Library.java:60)
1> org.elasticsearch.common.jna.Kernel32LibraryTests.testKernel32Library(Kernel32LibraryTests.java:74)

[s1monw]

this is related to #8993

[s1monw]

@tlrx can you comment on this. I really wonder if the native library we load here is worth the trouble?

[tlrx]

@rmuir thanks for spotting it.

Does the functionality or just the test need to create these proxies? Can we avoid it? Otherwise, we can add this permission, but it is a little bit strange that JNA for e.g. unix mlockall does not need to create proxies but on windows it does.

The functionality makes a native call on Windows to add a console control handler. The current implementation uses proxification which is the best documented way to make a native call on Windows with the JNA library. The other way is to use Direct Mapping like what is done in the unix/mlockall function.

If these proxy creation is really annoying, I think I can change the code to use Direct Mapping in Kernel32Library too.

Besides this, I didn't see a test for the Native.tryMlockall() method. I added one locally and it fails with SecurityManager enabled and the current test policy:

Caused by: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "createSecurityManager")

I really wonder if the native library we load here is worth the trouble?

#8993 relies on the SetConsoleCtrlHandler function and was added to ensure that a node is correctly shutdown on Windows when the user closes the console that starts Elasticsearch (either by clicking Close on the console window's window menu, or by clicking the End Task button command from Task Manager, or with a TASKILL command like a stop script would do). I really think that's very important to gracefully stop the node... Without this, it's like kill -9 the JVM.

So I suggest to keep the native library (it will also be used for the mlockall equivalent on Windows) and unify the way the native calls are made in CLibrary/Kernel32Libray and limit the permissions to grant in the policy file, and finally add a test for Native.tryMlockall().

[rmuir]

So I suggest to keep the native library (it will also be used for the mlockall equivalent on Windows) and unify the way the native calls are made in CLibrary/Kernel32Libray and limit the permissions to grant in the policy file, and finally add a test for Native.tryMlockall().

+1 that sounds great.

[s1monw]

cool stuff!!