> 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()) > > Gregory Chanan wrote: > 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.
Yes, the problem is only with setting the authentication menthod, which might overwrite a different value of this paramter in the configuration. And hence we should set this only if "sentry.service.security.mode" is kerberos. That way it always works for secure kereberos clients. And for other clients, login fails as expected. - Sravya ----------------------------------------------------------- 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 > >
