bug-gnulib
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]