[jira] [Comment Edited] (HIVE-3805) Resolve TODO in TUGIBasedProcessor

["Ashutosh Chauhan (JIRA)" <ji...@apache.org>]

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

Ashutosh Chauhan edited comment on HIVE-3805 at 12/15/12 6:53 PM:
------------------------------------------------------------------

If you look at hiveserver2 implementation over at HIVE-2935, it has an implementation of {{Plain}} sasl server. Plain server means sasl server doesn't use kerberos (or any authentication mechanism) for authenticating thrift client and at the same time client transfers end user identity to server. Server just trusts client, since its unsecure mode anyways. This Sasl server is used for thrift client and server transport in HiveServer2. That is much more cleaner approach than the current implementation which is really hacky which does an rpc call to transfer ugi (introduced in HIVE-2616 ), instead of transferring it at connection setup time. Though, current hacky approach works, its a twisted design and harder to understand. If there is any interest in wider adoption of transferring ugi for unsecure connection between thrift client and server, we should use HS2 mechanism. Further, since HiveServer2 already uses that, we will have parity in transport layer between HS2 client-server transport and metastore client-server transport. That way we can reuse code between these two transports, instead of having two parallel implementations of same feature.
                
      was (Author: ashutoshc):
    If you look at hiveserver2 implementation over at HIVE-2935, it has an implementation of {{Plain}} sasl server. Plain server means sasl server doesn't use kerberos (or any authentication mechanism) for authenticating thrift client and at the same time client transfers end user identity to server. Server just trusts client, since its unsecure mode anyways. This Sasl server is used for thrift client and server transport in HiveServer2. That is much more cleaner approach than the current implementation which is really hacky which does an rpc call to transfer ugi (introduced in HIVE-2616 ), instead of transferring it at connection setup time. Though, current hacky approach works, its a twisted design and harder to understand. If there is any interest in wider adoption of transferring ugi for unsecure connection between thrift client and server, we should use HS2 mechanism. Further, since HiveServer2 already uses that, we will have parity in transport layer between HS2 client-server transport and metastore client-server transport. 
                  
> Resolve TODO in TUGIBasedProcessor
> ----------------------------------
>
>                 Key: HIVE-3805
>                 URL: https://issues.apache.org/jira/browse/HIVE-3805
>             Project: Hive
>          Issue Type: Improvement
>          Components: Metastore
>    Affects Versions: 0.11
>            Reporter: Kevin Wilfong
>            Assignee: Kevin Wilfong
>         Attachments: HIVE-3805.1.patch.txt
>
>
> There's a TODO in TUGIBasedProcessor
> // TODO get rid of following reflection after THRIFT-1465 is fixed.
> Now that we have upgraded to Thrift 9 THRIFT-1465 is available.
> This will also fix an issue where fb303 counters cannot be collected if the TUGIBasedProcessor is used.

--
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