[
https://issues.apache.org/jira/browse/HADOOP-7083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12990719#comment-12990719
]
Todd Lipcon commented on HADOOP-7083:
-------------------------------------
We already have two other precedents for this type of config that I can think
of off the top of my head:
- dfs.block.access.token.enable can be set false and I don't think HDFS will
refuse to start.
- the MR Task Controller can be set to DefaultTaskController when other parts
of security are on, and MR will still function.
Do you consider those to be bugs?
There is always a tradeoff between security and convenience, and it should be
up to the user to decide where they want to be on the spectrum, so long as they
are very clear they are making this kind of trade-off. By naming and describing
the config clearly to indicate that they are losing security by configuring it
incorrectly, then who are we to stop them?
It seems you've picked some arbitrary point on this spectrum and decided that's
the only choice a user should have. I say the point is arbitrary because we
haven't gone all the way -- why doesn't Hadoop refuse to start if you're
running a Linux kernel with a known root escalation exploit? Why doesn't Hadoop
refuse to start if its configs are on a non-kerberized NFS filer? Why doesn't
Hadoop refuse to start if you aren't running SELinux? Should we refuse to
accept block writes from nodes outside the cluster because DNS spoofing attacks
can defeat the non-mutually-authenticated non-encrypted transport we use for
the xceiver protocol?
Some organizations might choose all of the above as their policies, but it's
not Hadoop's decision to enforce these things, because they're very
inconvenient. If my goal is to learn about how a kerberized cluster behaves, I
don't want all the hardening (and associated inconvenience) that a company
storing financial information would want.
It seems there's a fundamental philosophical disagreement here rather than one
about this particular JIRA. Should we bring this to a discussion on the mailing
lists rather than in these specific bugs?
> Allow SecureIO to be disabled for developer workstations
> --------------------------------------------------------
>
> Key: HADOOP-7083
> URL: https://issues.apache.org/jira/browse/HADOOP-7083
> Project: Hadoop Common
> Issue Type: Improvement
> Components: native, security
> Affects Versions: 0.22.0
> Reporter: Todd Lipcon
> Assignee: Alejandro Abdelnur
> Attachments: hadoop-7083.txt
>
>
> In testing with secure Hadoop, the new requirement for native code is
> annoying on platforms like OSX where the native code can be tricky to get
> compiled and working. We should allow developers to disable this aspect of
> security by setting a special flag.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
