[ 
https://issues.apache.org/jira/browse/LIVY-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yanchao resolved LIVY-595.
--------------------------
    Resolution: Fixed

this problem is livy bug,when GSSAPI negotiation is complete will return null 
byte,and livy send this null byte to driver, so we should not send null byte by 
the channel then remove this handler from the pipeline. thinks!

> Replace DEGEST-MED5 with GSSAPI(Kerberos) in the RPC sasl
> ---------------------------------------------------------
>
>                 Key: LIVY-595
>                 URL: https://issues.apache.org/jira/browse/LIVY-595
>             Project: Livy
>          Issue Type: Improvement
>          Components: RSC, Server
>    Affects Versions: 0.5.0
>            Reporter: yanchao
>            Priority: Blocker
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> This is a English version
> DIGEST-MD5 has been considered as a non-secure encryption mechanism in the 
> industry, so according to the company's security requirements, it is replaced 
> by GSSAPI (kerberos authentication);
> Initially, I just changed the configuration value of livy. rsc. rpc. sasl. 
> mechanisms to GSSAPI, but reported an error: Failed to find any Kerberos 
> credentails; so I started my painful journey to modify the source code (thank 
> you very much if you have a feasible configuration plan to inform). The 
> specific steps are as follows:
>  
> 1) In the Rpc and RpcServer classes, create LoginContext and login when 
> creating client and server for sasl, and encapsulate Sasl. createSaslServer 
> and Sasl. createSaslClient with Subject. doAs.
> 2) The parameters of Sasl. createSaslServer and Sasl. createSaslClient mainly 
> change protocol to the user name of principal (i.e. the first paragraph of 
> principal), and server Name to the qualified name of principal (i.e. the 
> second paragraph of principal). Other parameters remain unchanged and login 
> succeeds.
>  
> Question: Client and server can communicate, the first sendHello can succeed, 
> but the second time Livy returns token to driver, driver unwrap error: 
> {color:#FF0000}Caused by GSSException: Defective token detection (Mechanism 
> level: Wrap Token (new format): Cannot read all 12 bytes needed to form this 
> token!){color}
>  
> My analysis: I tracked livy's log. The byte array returned to driver is null 
> and sent to driver by Chanel Rpc.SaslMessage object, when unwrap, \{data is 
> [20, 1, 0, 0], offset is 0, len is 4}, driver unwrap will report an error.
>  
>  
> The problem is too difficult to solve, I need help now. thinks everyone.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to