[
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: [email protected]
For additional commands, e-mail: [email protected]
