[
https://issues.apache.org/jira/browse/HDFS-1150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12894237#action_12894237
]
Todd Lipcon commented on HDFS-1150:
-----------------------------------
bq. Until we support non-jsvc methods of doing this, it's not going to work to
have a non-jsvc verified datanode
The point is that we already "support" the SELinux way - you configure the
datanode to a high port, and then set up the SELinux policy to only allow the
HDFS user to bind that high port. No Hadoop-side support is necessary, but the
current implementation prohibits this mechanism, which I don't think is right.
bq. it would essentially be
my.cluster.is.secure.except.for.this.one.attack.vector, which is not a good
idea for the same reasons as above
Think of it like
i.already.secured.my.datanode.port.with.some.external.mechanism :) I'm OK with
this config being default to false (ie refuse to start non-secure), but it
needs to be configurable. The developer testing case you mentioned is another
good example.
> Verify datanodes' identities to clients in secure clusters
> ----------------------------------------------------------
>
> Key: HDFS-1150
> URL: https://issues.apache.org/jira/browse/HDFS-1150
> Project: Hadoop HDFS
> Issue Type: New Feature
> Components: data-node
> Affects Versions: 0.22.0
> Reporter: Jakob Homan
> Assignee: Jakob Homan
> Attachments: commons-daemon-1.0.2-src.tar.gz,
> HDFS-1150-BF-Y20-LOG-DIRS-2.patch, HDFS-1150-BF-Y20-LOG-DIRS.patch,
> HDFS-1150-BF1-Y20.patch, hdfs-1150-bugfix-1.1.patch,
> hdfs-1150-bugfix-1.2.patch, hdfs-1150-bugfix-1.patch, HDFS-1150-trunk.patch,
> HDFS-1150-Y20-BetterJsvcHandling.patch, HDFS-1150-y20.build-script.patch,
> HDFS-1150-Y20S-ready-5.patch, HDFS-1150-Y20S-ready-6.patch,
> HDFS-1150-Y20S-ready-7.patch, HDFS-1150-Y20S-ready-8.patch,
> HDFS-1150-Y20S-Rough-2.patch, HDFS-1150-Y20S-Rough-3.patch,
> HDFS-1150-Y20S-Rough-4.patch, HDFS-1150-Y20S-Rough.txt
>
>
> Currently we use block access tokens to allow datanodes to verify clients'
> identities, however we don't have a way for clients to verify the
> authenticity of the datanodes themselves.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
