[
https://issues.apache.org/jira/browse/HADOOP-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546064
]
Raghu Angadi commented on HADOOP-2184:
--------------------------------------
Why I think introducing new hierarchy of SocketFactories belongs in new Jira :
# It requires all the code from this Jira and does not obsolete any code here.
Yes, it will move some of the code, mainly writeHeader() in client and
processHeader() in Server.
# Fundamentally changes RPC format: now RPC connection header etc are moved out
of Sever into SocketFactories. May be before even reading "hrpc", there is some
other header that indicate what SocketFactory should be used on the Server
side. If this extra header is not required then not sure how Kerberos
encryption and authentication are handled.
# All the socket factories need to support non-blocking accepts and Server.java
needs to handle non-blocking accepts.. implementation is not hard... but
arriving at acceptable interface might be.
# SocketFactories should work nested.. we should able to use Socks proxy, just
like now.
To me it seems like quite a bit new code and more importantly large new
Interfaces. This does not yet add any new functionality for 16.
> 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
>
> Attachments: HADOOP-2184-demo.patch, HADOOP-2184-demo.patch,
> HADOOP-2184-demo.patch, HADOOP-2184-demo.patch, HADOOP-2184-demo.patch
>
>
> 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.
