hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daryn Sharp (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-9421) Convert SASL to use ProtoBuf and add lengths for non-blocking processing
Date Tue, 11 Jun 2013 22:35:20 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-9421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680770#comment-13680770

Daryn Sharp commented on HADOOP-9421:

bq.  As long as the mech is TOKEN (or better CHALLENGE_RESPONSE),
The authMethods are mapping an abstract name (ie. TOKEN) to the SASL mechanism.  With the
other security designs being discussed, we might have an ID_TOKEN or SSO_TOKEN.  The abstract
name appears in the stringified UGI, so it's not applicable to call it CHALLENGE_RESPONSE.

bq. why can't you instantiate the sasl client then (after receiving server challenge) with
the info from server challenge? Why would an additional roundtrip be necessary unless the
mech is not supported by server?

That's precisely the convoluted logic I outlined in steps 1-4.  It's a lot of additional complexity
to pre-maturely optimize just a reconnect, and introduces much more complexity.  Ex. If the
client's INITIATE is invalid, now the server can't return an fatal error and close the connection.
 It has to return NEGOTIATE.  However a second bad INITIATE should return a fatal error. 
The client has to know to create a SASL client on the first CHALLENGE, but not subsequent
CHALLENGES.  Other details rapidly add up.

As opposed to INITIATE means the client and server both instantiate their SASL objects at
that time.

bq. Trying to see why you're not seeing what I'm seeing: perhaps it's not obvious that SaslClient#hasInitialResponse
is always false for new connection with token (Digest-MD5 at least, cf. rfc-2831)?

Initial response is true for other mechanisms like GSSAPI and PLAIN, which means kerberos
has just been penalized.  If we upgrade the digest mechanism for tokens, that new mechanism
may also have an initial response.  We can't design this around an internal detail of one
particular mechanism (DIGEST-MD5).

Backing up, I thought we agreed earlier to defer reconnect optimizations to a future jira?
> Convert SASL to use ProtoBuf and add lengths for non-blocking processing
> ------------------------------------------------------------------------
>                 Key: HADOOP-9421
>                 URL: https://issues.apache.org/jira/browse/HADOOP-9421
>             Project: Hadoop Common
>          Issue Type: Sub-task
>    Affects Versions: 2.0.3-alpha
>            Reporter: Sanjay Radia
>            Assignee: Daryn Sharp
>         Attachments: HADOOP-9421.patch, HADOOP-9421.patch, HADOOP-9421.patch, HADOOP-9421.patch,

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

View raw message