hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Todd Lipcon (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-7083) Allow SecureIO to be disabled for developer workstations
Date Fri, 04 Feb 2011 20:11:34 GMT

    [ 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

        

Mime
View raw message