[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FTS not ready for a remount during traversal
From: |
Kamil Dudka |
Subject: |
Re: FTS not ready for a remount during traversal |
Date: |
Wed, 21 Oct 2009 22:25:33 +0200 |
User-agent: |
KMail/1.9.10 |
Hi Jim,
thanks for quick reply!
On Wednesday 21 of October 2009 21:47:59 Jim Meyering wrote:
> 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.
I agree.
> > 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.
That's exactly why I've written another patch. The patch proposed by me does
not bypass the ino/dev check on the return. It only updates the stat data
right after opening a directory.
> 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.
As probably "completely safe" solution we can trigger the mount before
statting a directory. But this will seriously affect the performance and
moreover introduce a change in behavior in e.g. find -fstype.
> 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.
Well, we can tell to kernel guys that the Linux NFS implementation is not
POSIX conforming and ask them to fix it. But in reality there is not much
they can do with this.
The only known "possible" solution is to trigger the mount within kernel on
each stat call to obtain the correct stat data. This will however punish all
applications, not only the applications which actually need it.
It is fairly well explained by Jeff Layton here:
https://bugzilla.redhat.com/show_bug.cgi?id=501848#c30
> To avoid this, perhaps the reporter can simply exclude the problematic
> .snapshot directories:
>
> du --exclude=.snapshot
Yes, but only in this specific case and only if we are not interested in
the space occupied by .snapshot directory.
Generally the problem is not specific to .snapshot directories at all. Two
nested NFS mount points are enough to raise the issue.
Kamil