[
https://issues.apache.org/jira/browse/HADOOP-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542567
]
Doug Cutting commented on HADOOP-2184:
--------------------------------------
> are there cases, where same client RPC connection is used both by
> infrastructure (not on user's behalf) as well as by the user
I would argue not. I think the JobTracker and TaskTracker processes should
have their own identity (non-root). User code should make files that the
JobTracker and TaskTracker must access (job.xml, job.jar, etc) readable by this
identity. Tasks should assume the identity of the user. So, under this
approach, the JobTracker and TaskTracker would never assume the user's
identity, only task sub-processes would. Is that workable?
It would be good to minimize the number of the user's files that the mapred
system must read. So ideally the file cache could be populated by a
sub-process with the user's identity. Similarly, moving the final output into
place must be done with the user's identity, and should thus be done in a
sub-process. So the only thing the kernel should really need to access is the
job configuration. We could pass that via RPC instead of through the
filesystem to remove even that.
> 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.
