Re: FTS not ready for a remount during traversal

[Jim Meyering]

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