> > In which case the check is not > > needed (if O_NOFOLLOW is also available). > > Unfortunately, we can't yet afford to target only systems with > open/O_NOFOLLOW support, and we do care about security on other systems.
I think you misunderstand. What I suggested is to get rid of the check and the lstat on systems which _do_ have O_NOFOLLOW. No security problem with this, is there? On systems which don't have O_NOFOLLOW, move the lstat() close to (or even after) the open. Again, no security issues. > The real problem is that these inode-less file systems violate > long-standing practice. And *many* applications depend on being able to > lstat a file and (soon afterward) open the same file, and then require > that the before and after inodes match. With an inode-less filesystem it is very very unlikely that the inode number will change between an lstat and a closely following open. As 'cp' is such an application, which is widely used, if this would happen in practice someone would have reported it. The problem with fts is that lstat and open can be very far apart, in the mean time the inode may (will, if the tree is deep enough and the memory is small enough) be flushed from the cache. > Have you considered changing FUSE so its caching mechanism is less likely > to flush data for active directory inodes? How do you define active? Most recently used? That's exactly how the Linux kernel caches inodes. Is that a hard guarantee, that the program won't be scheduled away between the lstat and the open, and exactly at that moment some other process needs a huge amount of memory, which shrinks the caches? No, that cannot be guaranteed. In that case the app will fail with some strange error. Tough luck. I think that's one more reason (other than being atomic, and more efficient) for using O_NOFOLLOW instead of lstat + open _if_ it's available. Miklos
