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

Christophe Taton commented on HADOOP-2184:
------------------------------------------

> Is it possible to have a situation that a RPC socket is shared by two 
> identities?
This might happen within the Eclipse plug-in. The plug-in actually may access 
many HDFS instances and many M/R infrastructures within the same JVM, which 
already caused me some headaches because of the client connections caching. 
However I don't know if this design of the plug-in should impose a design on 
the Hadoop core.

>> This to anticipate in HADOOP-1298 as I'm currently updating this issue.
> For now, I think no changes are necessary in HADOOP-1298 for this.
In fact, this issue might ease HADOOP-1298 a bit, as it would not require a 
change to the API: H-1298 currently adds a Ticket parameter to almost all 
methods of ClientProtocol. This would not be necessary anymore if this issue 
provides the ticket directly through the RPC layer.

> RPC Support for user permissions and authentication.
> ----------------------------------------------------
>
>                 Key: HADOOP-2184
>                 URL: https://issues.apache.org/jira/browse/HADOOP-2184
>             Project: Hadoop
>          Issue Type: New Feature
>          Components: ipc
>    Affects Versions: 0.15.0
>            Reporter: Tsz Wo (Nicholas), SZE
>            Assignee: Raghu Angadi
>             Fix For: 0.16.0
>
>
> Update 11/13/2007: What is proposed for 0.16.0 :
> The client can set a user ticket (as defined in HADOOP-1701) for each 
> connection and that ticket is made available to RPC calls at the server. The 
> client can replace the ticket at any time. The main advantage is that rest of 
> the the client RPCs don't need to be aware of the user tickets.
> What RPC would ideally support in future :
> In the current version of RPC, there is no authentication or data protection. 
>  We propose to change the RPC framework, so that secure communication is 
> possible.
> The new RPC should:
> - Compatible with current RPC
> - Allow a pluggable security implementations (see HADOOP-1701)
> - Support both secure and non-secure modes.
> Here is a rough idea:
> - Store security information (e.g. username, keys) in a ticket
> - Use the ticket to establish a RPC connection
> - Create secure sockets by the (subclass of) SocketFactory corresponding to 
> the selected security implementations
> - Send the data and RPC parameters with the secure sockets
> When authentication is supported, the RPC callee should also initialize 
> caller information during RPC setup and execute the RPC on the caller's 
> behalf.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to