[
https://issues.apache.org/jira/browse/LUCENE-9738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17280513#comment-17280513
]
Robert Muir commented on LUCENE-9738:
-------------------------------------
[~dweiss] I hadn't noticed this, never having the use-case to get permissions
in a fork join task.
Maybe the behavior relates to their intended use as sandboxed work units:
{noformat}
The efficiency of ForkJoinTasks stems from a set of restrictions (that are only
partially statically enforceable) reflecting their main use as computational
tasks calculating pure functions or operating on purely isolated objects ...
should ideally avoid synchronized methods or blocks, and should minimize other
blocking synchronization apart from joining other tasks ... should also not
perform blocking I/O, and should ideally access variables that are completely
independent of those accessed by other running tasks.
{noformat}
> 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]
