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

Vijay Bhat commented on HDFS-6666:
----------------------------------

[~arpitagarwal] 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. 

For the TestSecureNameNode class, I refactored it to use the 
SaslDataTransferTestCase utility as [~cnauroth] suggested - the class tests for 
Kerberos without needing to use the startKdc profile. Currently Kerberos test 
cases get skipped if we don't use the startKdc profile, so Jenkins seems to be 
skipping Kerberos test cases by default. By doing this refactor, we can ensure 
that this functionality is always tested. 

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). Please let me know your thoughts.

> 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)

Reply via email to