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 15:31:16 GMT

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

Daryn Sharp commented on HADOOP-9421:
-------------------------------------

Further thoughts.  Sorry it's so long, but I'm presenting the entire thought process I've
gone through.
# If the server is going to tell the client its identity (ex. what token, service principal,
etc is required for a mechanism), then the client doesn't have the foreknowledge to select
an appropriate mechanism.
# The client shouldn't be relying on the site config because it may not be valid in a heterogeneous
environment of clusters with different authentication requirements.  Requiring multiple configs
to access multiple clusters is becoming very cumbersome.
# Main point: there will always be 1 round-trip in any implementation.

*Using sasl-next*
Nominal case with token
O(1)
{noformat}
C -> S [ connection-header: ... ]
S -> C [ sasl-start: mech1, proto1, id1 ]
C -> S [ sasl-response: sasl-token ]
S -> C challenge, success, failure
{noformat}

No token
O(N), typically O(2)
{noformat}
C -> S [ connection-header: ... ]
S -> C [ sasl-start: mech1, proto1, id1 ]
C -> S [ sasl-next ]
S -> C [ sasl-start: mech2, proto2, id2 ]
C -> S [ sasl-response: sasl-token ]
S -> C challenge, success, failure
{noformat}

Discussion of server directing authentication:
# The state-machines for authentication are simple.  Server always initiates SASL sequence.
# Client is simple and "dumb"
#* Just tries to do what it's told
# Server is simple and deterministic
#* Trivially gives client a chance with each mechanism
#* Don't have to handle a client spamming auths and tying up an fd (ie. it will have to reconnect)
#* Don't have to handle tracking which auths have already been tried
#* Object creation to interrogate the mechanism id is deferred until needed
# Algorithmic complexity to negotiate a mechanism:
#* Technically the authentication exchange is O(N)
#* Tasks will be O(1)
#* Job submitters requiring a token will be O(N>1), typically O(2)

*Using server advertisement*
Server _does_ support client suggestion
Client _does_ possess the credential
O(1)
{noformat}
C -> S [ connection-header: ..., suggested-mech, suggested-proto ]
S -> C [ sasl-start: suggested-mech, suggested-proto, id ] // client needs server id
C -> S [ sasl-response: sasl-token ]
S -> C challenge, success, failure
{noformat}

Server _does_ support client suggestion
Client _does not_ actually possess the credential
O(3)
{noformat}
C -> S [ connection-header: ..., suggested-mech, suggested-proto ]
S -> C [ sasl-start: suggested-mech, suggested-proto, id ] // client needs server id
C -> S [ sasl-abort ] // uh-oh, client doesn't have the credentials for the server id!
S -> C [ sasl-mechs: [mech1, proto1, id1], [mech2, proto2, id2], ... ]
C -> S [ sasl-start: mech?, proto?, id? ]
S -> C [ sasl-challenge: sasl-token ]
C -> S [ sasl-response: sasl-token ]
S -> C challenge, success, failure
{noformat}

Server _does not_ support client suggestion
O(2)
{noformat}
C -> S [ connection-header: ..., suggested-mech, suggested-proto ]
S -> C [ sasl-mechs: [mech1, proto1, id1], [mech2, proto2, id2], ... ]
C -> S [ sasl-start: mech?, proto?, id?]
S -> C [ sasl-challenge: sasl-token ]
C -> S [ sasl-response: sasl-token ]
S -> C challenge, success, failure
{noformat}

Discussion of client directing authentication:
# The state-machines for authentication are more complex.  Either side can initiate SASL sequence.
# Client is smart/more complex
#* How can it select a mechanism?
#** Clients on a secure cluster always claim to be KERBEROS despite a TGT (arguably a bug)
#** Does the client try KERBEROS and fail?  Another round-trip
#** What if the client has multiple authenticated credentials available?  Does it randomly
pick one?
#** Or does it always request TOKEN and fail if it doesn't have one for the server id returned?
 Another round-trip
#* Might as well not suggest a mech/proto and wait for server to tell it what it can do...
# Server is smart and has more error cases to handle
#* Client can initially request an invalid auth, all server can do is respond with supported
mechs
#* More complex to allow a client to attempt each mechanism
#* Have to track which auths have been attempted to abort when all are exhausted
#* Server has to instantiate objects for all mechanisms to acquire server id
# Algorithmic complexity to negotiate a mechanism:
#* Is O(1) assuming client can select the correct mechanism, which it can't w/o server id
#* In practice O(2)
#* Has more complex implementation and maintainability costs


I'm concerned we are venturing into premature optimization.  In both cases, it's likely to
be O(2).  Sasl-next _might_ be O(>2) but of a low number during job submission.    RPC
connections are cached and multiplex higher level clients (such as DFSClient) so a possible
O(>2) is minimal one-time overhead.  Given that the actual SASL negotiation requires multiple
RPCs, ex. kerberos is at least 3, the difference between 3 and maybe 4 will only be measurable
with a micro-benchmark that connects & disconnects w/o performing operations.
                
> 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

Mime
View raw message