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

Aaron T. Myers commented on HDFS-3608:
--------------------------------------

I don't think that using inotify should be a hard requirement here. It might be 
acceptable, and quite a bit simpler, to just check the last modification time 
of the ticket cache file when fetching the cached Filesystem instance, and 
create a new FS if the mod time has changed since the last time it was accessed.

Given that, I think we should remove inotify from the summary of this JIRA.
                
> fuse_dfs: use inotify to detect changes in UID ticket cache
> -----------------------------------------------------------
>
>                 Key: HDFS-3608
>                 URL: https://issues.apache.org/jira/browse/HDFS-3608
>             Project: Hadoop HDFS
>          Issue Type: Bug
>    Affects Versions: 2.0.1-alpha
>            Reporter: Colin Patrick McCabe
>            Assignee: Colin Patrick McCabe
>            Priority: Minor
>
> Currently in fuse_dfs, if one kinits as some principal "foo" and then does 
> some operation on fuse_dfs, then kdestroy and kinit as some principal "bar", 
> subsequent operations done via fuse_dfs will still use cached credentials for 
> "foo". The reason for this is that fuse_dfs caches Filesystem instances using 
> the UID of the user running the command as the key into the cache.  This is a 
> very uncommon scenario, since it's pretty uncommon for a single user to want 
> to use credentials for several different principals on the same box.
> However, we can use inotify to detect changes in the Kerberos ticket cache 
> file and force the next operation to create a new FileSystem instance in that 
> case.  This will also require a reference counting mechanism in fuse_dfs so 
> that we can free the FileSystem classes when they refer to previous Kerberos 
> ticket caches.

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

        

Reply via email to