hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colin Patrick McCabe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-3568) fuse_dfs: add support for security
Date Tue, 03 Jul 2012 23:36:34 GMT

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

Colin Patrick McCabe commented on HDFS-3568:
--------------------------------------------

bq. I don't think there's any need to throw an exception if security is disabled when calling
fromKerberosTicketCache. The other methods in the class just return early or return default
values when security is disabled, e.g. reloginFromKeytab.

It's a little awkward because I'd essentially have to duplicate this code yet again:
{code}
if (user == null) {
  ugi = UserGroupInformation.getCurrentUser();
} else {
  ugi = UserGroupInformation.createRemoteUser(user);
}
{code}

The other alternative would be to return null and have the function callers proceed with their
normal flow of control in this case.  So something like this in FileSystem#get:
{code}
    String ticketCachePath =
      conf.get(CommonConfigurationKeys.KERBEROS_TICKET_CACHE_PATH);
    if (ticketCachePath != null) {
      ugi = UserGroupInformation.fromKerberosTicketCache(ticketCachePath);
    }
    if (ugi == null) {
       if (user == null) {
        ugi = UserGroupInformation.getCurrentUser();
       } else {
         ugi = UserGroupInformation.createRemoteUser(user);
       }
    }
{code}

bq. In hdfsConfGet, why do you return "EINTERNAL" in some cases and "-EINTERNAL" in others?

Yeah, I really should be sure to use the same convention everywhere... I think we've gone
with "always positive."  It's just that the kernel coding convention is that error numbers
are always negative, so I keep forgetting that ours is different...

bq. Are you positive that it's acceptable for all LoginContext objects to share the same reference
to a HadoopConfiguration object? Previous to this patch, each LoginContext would get it's
own new reference to a HadoopConfiguration object. (I don't know that it is definitely a problem,
I'm just not positive either way.)

The base class, javax.security.auth.login.Configuration contains only static variables.  And
HadoopConfiguration itself contains only static variables.  So it's hard to see what harm
could come from having them share the same object.

bq. Is there really no built-in function which already implements "jStrToCstr" ? (I don't
know that there is, I'm just surprised that there isn't.)

Ah, it looks like there is a built-in function.  Will fix.

bq. I recommend you rename hdfsBuilderSetNameNode to hdfsBuilderSetNameNodeHostname.

The problem is that the 'nn' parameter can have 4 different types of values:
* NULL - meaning always use LocalFileSystem
* The word "default" - meaning read the configuration, and do that
* the hostname of the NameNode
* the IP address of the NameNode

Since only one of those four is a hostname, calling it "...SetHostname" makes me a little
queasy.  But if the consensus is that we should call it that, then I'm open to that.

I agree with the rest of the comments, will fix.
                
> fuse_dfs: add support for security
> ----------------------------------
>
>                 Key: HDFS-3568
>                 URL: https://issues.apache.org/jira/browse/HDFS-3568
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>    Affects Versions: 1.0.0, 2.0.0-alpha
>            Reporter: Colin Patrick McCabe
>            Assignee: Colin Patrick McCabe
>             Fix For: 1.1.0, 2.0.1-alpha
>
>         Attachments: HDFS-3568.001.patch
>
>
> fuse_dfs should have support for Kerberos authentication.  This would allow FUSE to be
used in a secure cluster.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message