You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@sentry.apache.org by "Gregory Chanan (JIRA)" <ji...@apache.org> on 2015/04/04 03:11:33 UTC
[jira] [Commented] (SENTRY-678) Sentry-Solr Binding may not load
group mapping service correctly
[ https://issues.apache.org/jira/browse/SENTRY-678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14395440#comment-14395440 ]
Gregory Chanan commented on SENTRY-678:
---------------------------------------
Review request: https://reviews.apache.org/r/32847/
> Sentry-Solr Binding may not load group mapping service correctly
> ----------------------------------------------------------------
>
> Key: SENTRY-678
> URL: https://issues.apache.org/jira/browse/SENTRY-678
> Project: Sentry
> Issue Type: Bug
> Affects Versions: 1.3.0
> Reporter: Gregory Chanan
> Assignee: Gregory Chanan
> Fix For: 1.6.0
>
>
> The user sets up LdapGroupMapping in the core-site.xml config. Imagine this file is not on the classpath.
> Then, consider the following stacktrace:
> {code}
> at org.apache.hadoop.security.Groups.parseStaticMapping(Groups.java:104)
> at org.apache.hadoop.security.Groups.<init>(Groups.java:86)
> at org.apache.hadoop.security.Groups.<init>(Groups.java:66)
> at org.apache.hadoop.security.Groups.getUserToGroupsMappingService(Groups.java:280)
> at org.apache.hadoop.security.UserGroupInformation.initialize(UserGroupInformation.java:283)
> at org.apache.hadoop.security.UserGroupInformation.ensureInitialized(UserGroupInformation.java:260)
> at org.apache.hadoop.security.UserGroupInformation.loginUserFromSubject(UserGroupInformation.java:804)
> at org.apache.hadoop.security.UserGroupInformation.getLoginUser(UserGroupInformation.java:774)
> at org.apache.hadoop.security.UserGroupInformation.getCurrentUser(UserGroupInformation.java:647)
> at org.apache.hadoop.fs.FileSystem$Cache$Key.<init>(FileSystem.java:2753)
> at org.apache.hadoop.fs.FileSystem$Cache$Key.<init>(FileSystem.java:2745)
> at org.apache.hadoop.fs.FileSystem$Cache.get(FileSystem.java:2611)
> at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:370)
> at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:169)
> at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:354)
> at org.apache.hadoop.fs.Path.getFileSystem(Path.java:296)
> at org.apache.sentry.provider.file.SimpleFileProviderBackend.<init>(SimpleFileProviderBackend.java:118)
> at org.apache.sentry.provider.file.SimpleFileProviderBackend.<init>(SimpleFileProviderBackend.java:112)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
> at org.apache.sentry.binding.solr.authz.SolrAuthzBinding.getAuthProvider(SolrAuthzBinding.java:92)
> at org.apache.sentry.binding.solr.authz.SolrAuthzBinding.<init>(SolrAuthzBinding.java:65)
> {code}
> If you follow this, you'll notice the GroupMappingService is initialized with the default (classpath) Configuration, even though we always specified the Configuration to use. This may be a hadoop bug -- I'll file a separate jira for that -- but we should workaround and test this in the meantime.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)