[
https://issues.apache.org/jira/browse/HDFS-13322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16506188#comment-16506188
]
Istvan Fajth commented on HDFS-13322:
-------------------------------------
Hello [~fabbri],
thank you for the review, and the really constructive questions, please find my
answers below.
I agree with the first part, maybe one thing, the second string comparison can
yield to zero if the two strings are equal, otherwise to any number not just 1,
so the order between users will be decided based on the username first, then
based on the kerberos ticket cache file if the authentication method is
kerberos that was the aim of this change.
On the second part, performance is a concern of mine as well, but I did not
find a better way, as we are caching connections in the RB tree, and for this
to work we need to differentiate between connections with different ticket
cache path. The method is called on every file system access, and we may gain
performance if we cache the ticket cache path for a pid in cases where there is
an application that is using the fuse mount often and remains running. In case
where the user runs file system commands from a shell for example or from a
shell script, every command will have its own pid I believe (though I have not
tested) so this use case on the other hand can add on memory usage, and in edge
cases can also cause slowness. And also in this case we would need to take care
of the cleanup that introduce complexity. I haven't done any benchmarks on
this, but I think I can run some over the weekend, or early next week, let's
see how performance changes in different scenarios.
I am planning to run the following tests, let me know if you see it sufficient
to test around the perf difference:
- test 10k access of a file via cat command on a random file with and without
the patch
- test 10k access for the same file using a small java program that runs with
the same pid during the test with and without the patch
Though I do not see anything besides the increased complexity with the
pid<->krb_ticket_cache mapping being cached, so that might be as well a good
approach here. I can think of the following scenarios:
- there is a scheduler, that schedules different processes to run in different
environments (different KRB5CCNAME) but with the same user id, then pid can be
a good differentiation and we can spare the lookup for the path
- there is a scheduler that schedules different tasks in threads, in this case
threads are inheriting the environment, and a change in the ticket cache path
will not be detected if we cache it by pid, but this scenario will not fulfill
the need of different principals used for different tasks only if we introduce
a different inheritance of the security context of the caller which I think we
don't want to do.
Do you see any other scenarios? As if you don't, we can try to measure and see
the perf difference in fuse-dfs with KRB5CCNAME value cached for a pid, and
evicted the same way as connections are getting expired from the cache. What do
you think about this approach? I do not really have further ideas at the
moment, though while I am working on the testing, I will try to figure out
other feasible ways.
> 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]
