Kamil Dudka wrote: > the FTS module does not seem to be ready for a remount during traversal. > As a minimal example we can take the following situation: > > https://bugzilla.redhat.com/show_bug.cgi?id=501848#c20
Hi Kamil, Thanks for the heads up. However, ... > Descending a directory triggers a shrinkable mount which implies a change > of the device number. However FTS data structures keep the old value of > device number, not reflecting this change. And later, when returning back > to the same directory through "..", fts_safe_changedir() fails for no good > reason (caused by std_dev mismatch). It fails for a very good reason. A changed device number may indicate an attempt to subvert the traversal, even though the inode number is the same. > The attached patch seems to solve the problem by calling fstatat() again > after opening a directory (and updating the device number). The patch is > not supposed to be applied as-is. It's more likely an idea how the problem > could be solved. Maybe something like that might be available via an option > to keep the original behavior unchanged (and eventually gain better > performance in some cases). > > Another approach is a workaround proposed by Ondra: > > https://bugzilla.redhat.com/attachment.cgi?id=354464 > > Any idea how to solve the problem? Thanks in advance! I don't see how we can justify any such change. Being able to detect whether the traversal returns to a previously visited directory is required for security and reliability. Weakening that device/inode equality check by removing the device comparison part would leave every fts-using tool open to a particularly subtle -- but nonetheless serious -- type of attack. Even if you think you needn't worry about an attack (it's admittedly far-fetched for an attacker to be able to mount/unmount directories in a hierarchy being traversed) fts has to provide certain guarantees to its callers, and cannot do so if the device number of a directory being traversed may change between the pre- and post-visit contact. Besides, relaxing this check would allow a user's improbable "mv" command to change the course of their own in-progress rm -rf DIR, making it remove all of $HOME, rather than just the intended $HOME/DIR. In addition, I suspect that any file system for which a file's (or in our case, a directory's) device number may spontaneously change is not POSIX conforming. To avoid this, perhaps the reporter can simply exclude the problematic .snapshot directories: du --exclude=.snapshot Jim
