[
https://issues.apache.org/jira/browse/SOLR-13986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16985413#comment-16985413
]
Robert Muir commented on SOLR-13986:
------------------------------------
Attached "notyet" patch disables the execution, but triggers some
hadoop-related test failures. For example:
{noformat}
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=TestImpersonationWithHadoopAuth -Dtests.seed=99890C3603287BF
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=lkt
-Dtests.timezone=Europe/Podgorica -Dtests.asserts=true
-Dtests.file.encoding=ISO-8859-1
[junit4] ERROR 0.00s J3 | TestImpersonationWithHadoopAuth (suite) <<<
[junit4] > Throwable #1:
com.google.common.util.concurrent.UncheckedExecutionException:
java.security.AccessControlException: access denied ("java.io.FilePermission"
"<<ALL FILES>>" "execute")
[junit4] > at
__randomizedtesting.SeedInfo.seed([99890C3603287BF]:0)
[junit4] > at
com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2050)
[junit4] > at
com.google.common.cache.LocalCache.get(LocalCache.java:3951)
[junit4] > at
com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3973)
[junit4] > at
com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4957)
[junit4] > at
org.apache.hadoop.security.Groups.getGroups(Groups.java:228)
[junit4] > at
org.apache.solr.security.hadoop.ImpersonationUtil.getUsersFirstGroup(ImpersonationUtil.java:42)
[junit4] > at
org.apache.solr.security.hadoop.TestImpersonationWithHadoopAuth.setupClass(TestImpersonationWithHadoopAuth.java:74)
[junit4] > at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit4] > at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[junit4] > at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit4] > at
java.base/java.lang.reflect.Method.invoke(Method.java:567)
[junit4] > at java.base/java.lang.Thread.run(Thread.java:830)
[junit4] > Caused by: java.security.AccessControlException: access denied
("java.io.FilePermission" "<<ALL FILES>>" "execute")
[junit4] > at
java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
[junit4] > at
java.base/java.security.AccessController.checkPermission(AccessController.java:1036)
[junit4] > at
java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:408)
[junit4] > at
java.base/java.lang.SecurityManager.checkExec(SecurityManager.java:658)
[junit4] > at
java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1096)
[junit4] > at
java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1071)
[junit4] > at
org.apache.hadoop.util.Shell.runCommand(Shell.java:938)
[junit4] > at org.apache.hadoop.util.Shell.run(Shell.java:901)
[junit4] > at
org.apache.hadoop.util.Shell$ShellCommandExecutor.execute(Shell.java:1213)
[junit4] > at
org.apache.hadoop.security.ShellBasedUnixGroupsMapping.getUnixGroups(ShellBasedUnixGroupsMapping.java:200)
[junit4] > at
org.apache.hadoop.security.ShellBasedUnixGroupsMapping.getGroups(ShellBasedUnixGroupsMapping.java:97)
[junit4] > at
org.apache.hadoop.security.JniBasedUnixGroupsMappingWithFallback.getGroups(JniBasedUnixGroupsMappingWithFallback.java:51)
[junit4] > at
org.apache.hadoop.security.Groups$GroupCacheLoader.fetchGroupList(Groups.java:387)
[junit4] > at
org.apache.hadoop.security.Groups$GroupCacheLoader.load(Groups.java:321)
[junit4] > at
org.apache.hadoop.security.Groups$GroupCacheLoader.load(Groups.java:270)
[junit4] > at
com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3527)
[junit4] > at
com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2276)
[junit4] > at
com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2154)
[junit4] > at
com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2044)
[junit4] > ... 29 more
{noformat}
This is what I expected would happen, hadoop has really bad code here. In
general it expects to run a bunch of shell commands and parse output (instead
of e.g. invoking proper java apis). When it runs these shell commands, it only
handles IOException and not SecurityException, so it fails completely.
One approach I used to tame this hadoop code before, is a custom Policy
subclass,that sneaky-rethrows an IOException to this specific hadoop code
instead of a SecurityException:
https://github.com/elastic/elasticsearch/blob/bf5866048262d897ede629293b6fe26c3b108b7a/server/src/main/java/org/elasticsearch/bootstrap/ESPolicy.java#L88-L99
> remove "execute" permission from solr-tests.policy
> --------------------------------------------------
>
> Key: SOLR-13986
> URL: https://issues.apache.org/jira/browse/SOLR-13986
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Robert Muir
> Priority: Major
> Attachments: SOLR-13986-notyet.patch
>
>
> If we don't really need to execute processes, we can take the permission
> away. That way any attempt to execute something results in a
> SecurityException rather than running a process.
> It is necessary to first fix the tests policy before thinking about
> supporting securitymanager in solr. This way we can ensure functionality does
> not break via our tests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
