[
https://issues.apache.org/jira/browse/LUCENE-9738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17280524#comment-17280524
]
Uwe Schindler commented on LUCENE-9738:
---------------------------------------
That's perfectly understandable from a security perspective. As soon as you
enable a security manager you want to control what code is doing. If you send
some task to an arbitrary thread you haven't created, it should really have no
permissions.
> Odd behavior with tests forked into the default ForkJoinPool
> ------------------------------------------------------------
>
> Key: LUCENE-9738
> URL: https://issues.apache.org/jira/browse/LUCENE-9738
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Dawid Weiss
> Assignee: Dawid Weiss
> Priority: Minor
> Attachments: LUCENE-9738.patch
>
>
> Just for the record, this will perhaps save somebody some search time. This
> test currently fails with out test policy:
> {code}
> public void testInsanity() throws ExecutionException, InterruptedException {
> // This is fine. This property should be read-accessible to anything in
> Java.
> System.getProperty("line.separator");
> // but this fails:
> ForkJoinTask<String> task =
> ForkJoinPool.commonPool()
> .submit(() -> System.getProperty("line.separator"));
> // Wait a bit to avoid job stealing.
> Thread.sleep(1000);
> task.get();
> {code}
> The above fails with a cryptic exception:
> {code}
> Caused by: java.security.AccessControlException: access denied
> ("java.util.PropertyPermission" "line.separator" "read")
> at
> java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> at
> java.base/java.security.AccessController.checkPermission(AccessController.java:1036)
> at
> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:408)
> at
> java.base/java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1152)
> at java.base/java.lang.System.getProperty(System.java:847)
> at
> org.apache.lucene.TestPermissionsInsanity.lambda$testInsanity$0(TestPermissionsInsanity.java:38)
> at
> java.base/java.util.concurrent.ForkJoinTask$AdaptedCallable.exec(ForkJoinTask.java:1453)
> at
> java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
> at
> java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1016)
> at
> java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1665)
> at
> java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1598)
> at
> java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:177)
> {code}
> What's odd here is that we only have java.base classes and our own test class
> on the stack. Seems like by default forkjoin executors have some kind of
> protection domain that disallows everything... Escaping through
> AccessController works but it's still surprising that it's not a built-in
> thing.
> Or maybe I misunderstand something, don't know...
> CC [~rmuir] - you may find this interesting.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
