hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arpit Agarwal (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-6666) Abort NameNode and DataNode startup if security is enabled but block access token is not enabled.
Date Wed, 08 Apr 2015 20:52:12 GMT

    [ https://issues.apache.org/jira/browse/HDFS-6666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14486002#comment-14486002
] 

Arpit Agarwal commented on HDFS-6666:
-------------------------------------

Thanks for the response [~vijaysbhat].
bq. Arpit Agarwal I need to check for the kerberos enabled (UserGroupInformation.isSecurityEnabled())
setting too right? My understanding of the issue was that we don't want the data node to fail
down the line because the block access token config was disabled and Kerberos was enabled.
I meant we have a check for earlier in the function to return if {{UserGroupInformation.isSecurityEnabled()}}
is false so the second check is redundant.

{code}
    if (!UserGroupInformation.isSecurityEnabled()) {
      return;
    }

    // Abort out of inconsistent state if Kerberos is enabled
    // but block access tokens are not enabled.
    boolean isEnabled = conf.getBoolean(
        DFSConfigKeys.DFS_BLOCK_ACCESS_TOKEN_ENABLE_KEY,
        DFSConfigKeys.DFS_BLOCK_ACCESS_TOKEN_ENABLE_DEFAULT);
    if (!isEnabled && UserGroupInformation.isSecurityEnabled()) {
{code}

bq. As for what the code is doing in TestSecureNameNode#testName, I am trying to mirror the
intent of the original test case - after Kerberos authentication, the root user can create
new directories, but a user other than root cannot create directories where it does not have
write access (substituting current user for user1).
Okay. The only minor concern would be the test fails if the logged in user is {{hdfs}}. How
about generating a random user name?

{code}
@@ -82,7 +83,7 @@ public static void initKdc() throws Exception {
     kdc.start();

-    String userName = UserGroupInformation.getLoginUser().getShortUserName();
+    String userName = RandomStringUtils.randomAlphabetic(8);
{code}

Also an assertion message in {{testName}} still references user1.

{code}
        Path p = new Path("/users/mydir");
        fs.mkdirs(p);
        fail("user1 must not be allowed to write in /users");
{code}

Looks good otherwise.

> Abort NameNode and DataNode startup if security is enabled but block access token is
not enabled.
> -------------------------------------------------------------------------------------------------
>
>                 Key: HDFS-6666
>                 URL: https://issues.apache.org/jira/browse/HDFS-6666
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: datanode, namenode, security
>    Affects Versions: 3.0.0, 2.5.0
>            Reporter: Chris Nauroth
>            Assignee: Vijay Bhat
>            Priority: Minor
>         Attachments: HDFS-6666.001.patch
>
>
> Currently, if security is enabled by setting hadoop.security.authentication to kerberos,
but HDFS block access tokens are disabled by setting dfs.block.access.token.enable to false
(which is the default), then the NameNode logs an error and proceeds, and the DataNode proceeds
without even logging an error.  This jira proposes that this it's invalid to turn on security
but not turn on block access tokens, and that it would be better to fail fast and abort the
daemons during startup if this happens.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message