> On Jan. 29, 2016, 6:56 p.m., Sravya Tirukkovalur wrote: > > From this > > (https://github.com/apache/incubator-sentry/blob/95b1e40e7062343f05e131afaea0a97bbf71ba4f/sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/provider/db/generic/service/thrift/SentryGenericServiceClientDefaultImpl.java#L127) > > , it looks like the client is using property > > "sentry.service.security.mode" to get the authentication mechanism. I dont > > think clients should be required to set this property. We should fix this > > in Sentry service/client if possible. Where in the client did you find > > looking up the hadoop property?
Good question. The issue is initializing hadoop's UserGroupInformation, which we are using for authentication. See: https://github.com/apache/incubator-sentry/blob/95b1e40e7062343f05e131afaea0a97bbf71ba4f/sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/provider/db/generic/service/thrift/SentryGenericServiceClientDefaultImpl.java#L83 That sets the authentication mechanism based on "hadoop.security.authentication". By default that is retrieved from "new Configuration()" (default: SIMPLE). So, if you have hadoop configuration on the classpath that sets "hadoop.security.authentication" to "kerberos" everything works, otherwise it doesn't. I think it makes sense for us to set hadoop.security.authentication in the client generally because we have our own property for authentication; just because there is some hadoop configuration on the classpath that uses kerberos (for hadoop!) doesn't mean we should be using that for anything. The trickiness comes in setting the configuration statically (UserGroupInformation.setConfiguration). We need to do this otherwise the configuration doesn't get picked up. This sets the configuration for the entire process, though, so if your process is doing other hadoop-related things (e.g. reading off hdfs), it can affect it. That was the nice thing about setting it in the shell; we know the shell is essentially a standalone process that isn't going to be doing other hadoop related things. Given the limitations of hadoop-auth, though, we should probably just set the configuration there. - Gregory ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/42933/#review116984 ----------------------------------------------------------- On Jan. 29, 2016, 1:32 a.m., Gregory Chanan wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/42933/ > ----------------------------------------------------------- > > (Updated Jan. 29, 2016, 1:32 a.m.) > > > Review request for sentry. > > > Repository: sentry > > > Description > ------- > > From the jira: > Today, the SentryShellSolr follows the same pattern as SentryShellHive, which > is just getting a "new Configuration()". In order to connect to a service > requiring kerberos, the Configuration must have > "hadoop.security.authentication" set to "kerberos" since the generic client > uses hadoop-auth to do the authentication. But this will often not be set in > the context of Solr, which may not even have a hadoop-related configuration > around. > > So, we should handle the configuration in the same way as we do for the > binding; namely, if the client intends to use kerberos, we set > "hadoop.security.authentication" to "kerberos" > > > Diffs > ----- > > > sentry-provider/sentry-provider-db/src/main/java/org/apache/sentry/provider/db/generic/tools/SentryShellSolr.java > ec786a546b9def25e5b4c9d22ae5b49b79982c88 > > Diff: https://reviews.apache.org/r/42933/diff/ > > > Testing > ------- > > Tested on a cluster where sentry-site.xml does not specify > hadoop.security.authentication and there are no other Configuration files on > the classpath. > > > Thanks, > > Gregory Chanan > >
