> 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? > > Gregory Chanan wrote: > 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. > > Sravya Tirukkovalur wrote: > Thanks for the explanation Greg! So it seems like it is still safe to > just bring in > new Configuration() and setting hadoop.security.authentication followed > by setting UseGroupInformation.setconf to the > SentryGenericServiceClientDefaultImpl just before the UGI.getloginUser(). > That way, future services would not have to do the workaround themselves? > > Gregory Chanan wrote: > You are correct except I would change "still safe" to "still safe as long > as the client process is not doing other hadoop-auth operations" > > Sravya Tirukkovalur wrote: > Even if they are doing other operations, as we are loading the > configurations via new Configurations() anyways isnt it? (Otherwise they > would be loaded inside getloginUser())
the issue is that you set the global configuration in UserGroupInformation.setConfiguration(...). So imagine this set of events in the same process: - Using generic client, set hadoop.security.authentication to kerberos via UGI.setConfiguration(...) - Use some other client, using some other authentication method. The UGI's configuration will still be using kerberos, so could have issues. Could call UGI.setConfiguration again, although I don't know how that will affect the on going generic client operations. In any case, I don't know if this is even fixable, just wanted to bring it up. - 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 > >
