[jira] [Commented] (HDFS-13322) fuse dfs - uid persists when switching between ticket caches

["Aaron Fabbri (JIRA)" <ji...@apache.org>]

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

Aaron Fabbri commented on HDFS-13322:
-------------------------------------

Thank you for the patch [~pifta]. This code is new to me, so shout if I misread somthing.  Left some inline comments here:

{noformat}
 static int hdfsConnCompare(const struct hdfsConn *a, const struct hdfsConn *b)
 {
-  return strcmp(a->usrname, b->usrname);
+  int rc = strcmp(a->usrname, b->usrname);
+  if (rc) return rc;
// AF: here we know the usernames are equal since rc == 0 
+  return gHdfsAuthConf == AUTH_CONF_KERBEROS && strcmp(a->kpath, b->kpath);
// AF: If auth is not kerb, we return 0 (equal), ok
// AF: if auth is kerb, we return 0 if kpath's are equal (ok), or 1 if they are not.
 }
 {noformat}

This is the comparator for a RB tree of hdfsConn objects by username, so ordering needs to be consistent. Looks like kpath is immutable once the conn is created, and we only have a few cache files in use, so this should be ok.

{noformat}
@@ -542,8 +546,13 @@ static int fuseConnect(const char *usrname, struct fuse_context *ctx,
   int ret;
   struct hdfsConn* conn;
 
+  char kpath[PATH_MAX] = { 0 };
+  if (gHdfsAuthConf == AUTH_CONF_KERBEROS) {
+    findKerbTicketCachePath(ctx, kpath, sizeof(kpath));
+  }
{noformat}

It looks like this is fast-path code (called on most fuse ops), and this change would add a good amount of overhead. I'd expect a performance regression.

I'm wondering if we need to cache the path in the KRB5CCNAME by pid or something.  Any other ideas?  Parsing /proc entries on every FS operation seems bad.



> fuse dfs - uid persists when switching between ticket caches
> ------------------------------------------------------------
>
>                 Key: HDFS-13322
>                 URL: https://issues.apache.org/jira/browse/HDFS-13322
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: fuse-dfs
>    Affects Versions: 2.6.0
>         Environment: Linux xxxxxx.xx.xx.xxx 3.10.0-514.el7.x86_64 #1 SMP Wed Oct 19 11:24:13 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux
>  
>            Reporter: Alex Volskiy
>            Assignee: Istvan Fajth
>            Priority: Minor
>         Attachments: HDFS-13322.001.patch, HDFS-13322.002.patch, HDFS-13322.003.patch, testHDFS-13322.sh, test_after_patch.out, test_before_patch.out
>
>
> The symptoms of this issue are the same as described in HDFS-3608 except the workaround that was applied (detect changes in UID ticket cache) doesn't resolve the issue when multiple ticket caches are in use by the same user.
> Our use case requires that a job scheduler running as a specific uid obtain separate kerberos sessions per job and that each of these sessions use a separate cache. When switching sessions this way, no change is made to the original ticket cache so the cached filesystem instance doesn't get regenerated.
>  
> {{$ export KRB5CCNAME=/tmp/krb5cc_session1}}
> {{$ kinit user_a@domain}}
> {{$ touch /fuse_mount/tmp/testfile1}}
> {{$ ls -l /fuse_mount/tmp/testfile1}}
> {{ *-rwxrwxr-x 1 user_a user_a 0 Mar 21 13:37 /fuse_mount/tmp/testfile1*}}
> {{$ export KRB5CCNAME=/tmp/krb5cc_session2}}
> {{$ kinit user_b@domain}}
> {{$ touch /fuse_mount/tmp/testfile2}}
> {{$ ls -l /fuse_mount/tmp/testfile2}}
> {{ *-rwxrwxr-x 1 user_a user_a 0 Mar 21 13:37 /fuse_mount/tmp/testfile2*}}
> {{   }}{color:#d04437}*{{** expected owner to be user_b **}}*{color}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org