I may be mistaken, but let me try again with an example to see if we are on the 
same page

Principals
 - NameNode: nn/nn-h...@cluster.com
 - DataNode: dn/_h...@cluster.com

Auth to local mappings
 - nn/nn-h...@cluster.com -> hdfs
 - dn/.*@cluster.com -> hdfs

The combination of the above lets you block any other user other than hdfs from 
faking like a datanode.

Purposes
 - _HOST: Let you deploy all datanodes with the same principal value in all 
their configs.
 - Auth-to-local-mapping: Map kerberos principals to unix-login names to close 
the loop on identity

Don't think your example of "somebody on an untrusted client can disguise as 
hdfs/nodename@REALM" is possible at all with Kerberos. Any references to such 
possibilities? If it were possible, all security is toast anyways, no?

+Vinod


> Thanks, I may be mistaken, but I suspect you missed the point:
> 
> for me, auth_to_local's role is to protect the server(s). For example,  
> somebody on an untrusted "client" can disguise as hdfs/nodename@REALM and 
> hence take over hdfs through a careless principal->id translation. A 
> well-configured auth_to_local will deflect that rogue "hdfs" to "nobody" or 
> something, so a malicious client cannot do a "hdfs dfs -chown ..." for 
> example.
> 
> The _HOST construct makes using the same config files throughout the cluster 
> easier indeed, but as far as I see it mainly applies to the "client".
> 
> On the server, I see no way other than auth_to_local with a list/pattern of 
> trusted node names (on namenode and every datanode in the hdfs case) to 
> prevent the scenario above. Would there be?



-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.

Reply via email to