On Wed, Jan 31, 2018 at 5:30 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > On Wed, Jan 31, 2018 at 09:34:52AM +0200, Amir Goldstein wrote: >> If filesystem were to provide a parents iterator interface, something like: >> get_acceptable_parent(child, acceptable, context) >> then xfs could iterate inode parents and call the nfsd_acceptable() callback. >> For filesystems that support get_acceptable_parent(), there is no need to >> encode a 'connectable' non unique file handle. >> >> I am not sure how much of a problem the 'subtree_check' and non-unique >> file handle is for nfsd (CC nfsd folks for that), but I know I can make good use >> of that in overlayfs, as well as with an optimized get_name() implementation. > > I hate subtree-checking and wish people would just stop trying to export > subtrees. > > That said, anything that makes it less painful is probably good. > > And, yes, the fact that filehandles can change when a file is renamed > across directories can be a problem for people using subtree checking. > Let's talk about your feeling about 'subtree_check' ... I hate security in general and wish that users would let us develop cool stuff and stop worrying so much about their hopeless quest for secure systems ;-) That said, I don't believe they will listen to us cool reckless guys. So despite your feeling, I am guessing that 'subtree_check' is here to stay and that nfsd should strive to a solution of unique and connectable file handles from filesystems that can support it. The question is: is the interface I proposed going to be adequate for 'subtree_check' requirement. Meaning, with current 'subtree_check' implementation, the decoded dentry is guarantied to have the same parent that was used for encoding the non-dir, although it does not guaranty to get the exact same alias. With the interface I proposed get_acceptable_parent() could decode an alias that is not even under the original parent directory. Do you see that as a problem? Cheers, Amir.
