[ 
https://issues.apache.org/jira/browse/HIVE-4232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13622931#comment-13622931
 ] 

Chris Drome commented on HIVE-4232:
-----------------------------------

I was thinking about this a little more and would like to summarize the current 
state:

hive-site.xml -> transport -> JDBC connection string

1. hive.server2.authentication=NOSASL -> raw transport -> 
jdbc:hive2://host:port/dbname;auth=noSasl
2. hive.server2.authentication=NONE -> plain SASL transport -> 
jdbc:hive2://host:port/dbname   (*DEFAULT*)
3. hive.server2.authentication=KERBEROS -> Kerberos SASL transport -> 
jdbc:hive2://host:port/dbname;principal=<principal>

So we need to set auth=noSasl to disable SASL instead of 
auth=plainsasl|kerberos to enable SASL.

Now if the server is set to Kerberos, then the client still has to know this 
because it if they exclude the principal parameter it will happily initialize a 
plain SASL transport because the code infers SASL/Kerberos based on the 
existence of that value. Granted, in this case the connection throws an 
exception.

If it was a requirement to include say auth=plainsasl|kerberos in the 
connection string, then the code wouldn't have to guess what the intent was and 
could communicate an error if auth=kerberos and principal is not present.

Furthermore, from what I can see, the plain SASL is really just a no-op as it 
is not doing anything when authentication=NONE.

In the end, it comes down to the fact that the client still needs to know the 
authentication method of the server.
That is why I asked whether we had data about the average use case. Do we know 
how often people are using raw vs plain vs kerberos?

It seems that the real issue is that a SASL transport doesn't play nicely with 
a raw transport. If it would be possible to remove the need to support the raw 
transport, that would resolve this discussion. Even the raw transport much 
speak thrift, so that isn't an issue. Rather it is a question of whether client 
should be forced to implement a SASL transport.
                
> JDBC2 HiveConnection has odd defaults
> -------------------------------------
>
>                 Key: HIVE-4232
>                 URL: https://issues.apache.org/jira/browse/HIVE-4232
>             Project: Hive
>          Issue Type: Bug
>          Components: HiveServer2, JDBC
>    Affects Versions: 0.11.0
>            Reporter: Chris Drome
>            Assignee: Chris Drome
>             Fix For: 0.11.0
>
>         Attachments: HIVE-4232-1.patch, HIVE-4232.patch
>
>
> HiveConnection defaults to using a plain SASL transport if auth is not set. 
> To get a raw transport auth must be set to noSasl; furthermore noSasl is case 
> sensitive. Code tries to infer Kerberos or plain authentication based on the 
> presence of principal. There is no provision for specifying QOP level.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to