Jim,
Any news about this bug?
This problem was again reported against a recent Debian release here:
http://article.gmane.org/gmane.comp.file-systems.fuse.sshfs/1200
Thanks,
Miklos
On Wed, 16 Jun 2010, Jim Meyering wrote:
> Miklos Szeredi wrote:
> > On Wed, 16 Jun 2010, Jim Meyering wrote:
> >> Miklos Szeredi wrote:
> >> > On Thu, 03 Jun 2010, Miklos Szeredi wrote:
> >> >> Hmm, actually "struct statfs" on linux does have
On Wed, 16 Jun 2010, Jim Meyering wrote:
> Miklos Szeredi wrote:
> > On Thu, 03 Jun 2010, Miklos Szeredi wrote:
> >> Hmm, actually "struct statfs" on linux does have f_frsize, only the
> >> manpage doesn't document it. So correct thing would be to use
Hi,
I've tried out the CVS version of findutils+gnulib, and it does indeed
seem to fix the problem with inode-less filesystems, in addition to
using noticably less system time.
I've also found that the -xdev option of find no longer works: it
outputs just a single line for the base directory.
Lo
> Separating the patch into parts wasn't really an option after all.
> I've checked this in:
Looks great. Thanks.
What's the easiest way to try this out? The patch doesn't apply to
the gnulib present in findutils-4.3.1, and I have no idea how to graft
a new gnulib version into findutils.
Thank
Looking at the strace there seems to be some other room for
optimization:
> open("a", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 5
> fstat64(5, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> fcntl64(5, F_SETFD, FD_CLOEXEC) = 0
Seems unnecessary, unless find was given -exec argument.
> That's close.
> To clarify: with the current fts implementation, the interval between the
> initial lstat and subsequent open of the same directory may be arbitrarily
> long, but only for 2nd or subsequent command-line arguments -- which
> usually translates to 2nd or subsequent members of the ar
> >> > 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.
>
> Not hardly.
>
> > Wh
> > 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 an
> > > But what about symlinks?
> > >
> > > a g
> > >b h->a
> > > c
> > > f->g
> > >
> > > The moment you traverse the f->g symlink above,
> > > the entire tree, a/b/c/f, is no longer referenced,
> > > so the h->a link may take you back to a new inode,
> > > and the cycle
> So I think the problem we are seeing is not for traversing up the
> tree, but for traversing down it. In which case the check is not
> needed (if O_NOFOLLOW is also available).
And if O_NOFOLLOW is unavailable it would still make sense to move the
stat and the open as close to each other as pos
> > But what about symlinks?
> >
> > a g
> >b h->a
> > c
> > f->g
> >
> > The moment you traverse the f->g symlink above,
> > the entire tree, a/b/c/f, is no longer referenced,
> > so the h->a link may take you back to a new inode,
> > and the cycle will not be detected
> >
> > Shouldn't holding the current directory open prevent the ancestor from
> > changing inodes in this case?
>
> No.
> What's changed is the identity (dev/inode) of the parent directory,
> once you try to chdir("..") "up" beyond the renamed directory.
I understand, that that is the case you w
> >> For example, consider the classic symlink attack.
> >> We're not supposed to follow symlinks and our system lacks support
> >> for open's O_NOFOLLOW flag. So we lstat the target directory,
> >> determine that it is indeed a directory, then open it. But between
> >> the lstat and the open, so
> For example, consider the classic symlink attack.
> We're not supposed to follow symlinks and our system lacks support
> for open's O_NOFOLLOW flag. So we lstat the target directory,
> determine that it is indeed a directory, then open it. But between
> the lstat and the open, someone moved it
> But what about symlinks?
>
> a g
>b h->a
> c
> f->g
>
> The moment you traverse the f->g symlink above,
> the entire tree, a/b/c/f, is no longer referenced,
> so the h->a link may take you back to a new inode,
> and the cycle will not be detected.
Right. So find eit
> > This one should work, since the file descriptor in the working
> > directory should prevent the inode from going away. Or is there
> > something I'm missing?
>
> We like to have a way of searching a directory hierarchy 10 levels
> deep without needing to have 10 open file descriptors.
> I suspect that it is possible, and maybe even feasible, to work around
> this violation of fundamental assumptions in some limited cases.
> However, in general, I think it's not possible, or at least not
> worth the effort.
>
> In spite of that, I have thought about changing fts to be usable eve
> > Look at this strace snipplet from 'find /mnt/fuse/tmp/test':
> >
> > lstat64("/mnt/fuse/tmp/test", {st_dev=makedev(0, 14), st_ino=3}...) = 0
> ...
> > open ("/mnt/fuse/tmp/test", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY)
> > = 5
> > fstat64(5, {st_dev=makedev(0, 14), st_ino=5}) = 0
>
> >
> Thanks for forwarding that.
> I confess I hadn't looked at the original bug report.
> Just did, and see that it's a different problem than I first thought.
> I now see that this is about the dev/ino check when traversing "up"
> to return to a previously visited directory.
>
> I find it hard to b
20 matches
Mail list logo
