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) Add full length to SASL response to allow non-blocking readers
Date Wed, 24 Apr 2013 17:47:19 GMT

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

Daryn Sharp commented on HADOOP-9421:

bq. Only if there is only one kind of tokens, which will not be true.

Valid point, but I'm interested in your vision/use-case for multiple tokens?  Could this be
hidden behind the secret manager?

bq. Benoy: An alternative approach in choosing a mechanism is to model after the SSL protocol.
Here Client does "ClientHello" to server with a list of mechanisms it supports.

Exploring that approach, why not return the mechanisms in response to the connection header?

bq. In terms of complexity. Sasl-next proposal actually seems more complex by intertwine sasl
handshakes with mechanism/protocol selection/negotiation.

I'm open to ideas, but I'm not sure I understand this.  How is "do you do this mech?", "no?",
"how about this mech?", "yes? ok, let's do it!" being complex?

bq. This is a generalization of the client initiation mechanism. If we implement my proposal,
this can be added later in a backward compatible manner, as we can send the client capabilities
in an optional field.

In your example, you're again assuming the client is in a position to intelligently _propose_
a mechanism - it's not.  The client can't make a determination until he knows the server id
for a mechanism.  

The server can't _chose_ a mech based client capabilities either.  Just because the client
and server support DIGEST-MD5/dtoken doesn't mean the client actually has the right token.
 The server can't guess what the client has, nor would be desirable for the client to send
all his token services so the server can chose.

The client is the one that must chose a mech but it needs server hints to do so.  I think
a middle ground is the server advertises all its mechs at once, instead of one at a time as
I proposed.
C -> S [ connection-header: ... ]
S -> C [ sasl-mechs: [mech1, proto1, id1], [mech2, proto2, id2], ... ]
C -> S [ sasl-start: mech?, proto? ]

Having only one side (in this case client) start the negotiation is much simpler.  If we say
the client gets one shot, instead of willy-nilly choosing multiple mechs and the server keeping
track of what's been attempted, then it will be a lot easier.  

The one downside I see to the client initiating the exchange, instead of the server, is if
the server wants to do a second mech based on success of another mech.  Ex. using some special
mech with a secret requires a followup sasl negotiation with say kerberos.  If the server
always initiates, and the dumb client does what it's told, that's easy to do in a trivial
fashion.  IMHO, dumb clients are always good, but I'm willing to compromise.
> Add full length to SASL response to allow non-blocking readers
> --------------------------------------------------------------
>                 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: Junping Du
>         Attachments: 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