From: Dave Chinner <david@fromorbit.com>
To: Paul Nienaber <phox@uvic.ca>
Cc: xfs@oss.sgi.com
Subject: Re: xfs_quota: bug: traverses bind mountpoints
Date: Fri, 8 Jul 2011 13:23:51 +1000 [thread overview]
Message-ID: <20110708032351.GF1026@dastard> (raw)
In-Reply-To: <4E161B1D.90301@uvic.ca>
On Thu, Jul 07, 2011 at 01:46:21PM -0700, Paul Nienaber wrote:
> So, much like coreutils' du (which also shouldn't), xfs_quota
> traverses bind mountpoints both when doing 'project -s' and 'project
> -C', and probably also 'project -c' although I haven't tested it.
> Testcase and output follows.
How is a userspace traversal supposed to detect the fact it crosses
a bind mount when it enters a directory? If you bind a directory
from the same filesystem, stat(2) on the file returns -identical-
information regardless of whether you are inside or outside the bind
mount. So the normal mechanisms (e.g. st_dev changes) for detecting
such a mount point traversal simply don't work.
So the first question is whether we should be trying to detect bind
mounts within the same filesystem and handling them for project
quotas? I don't know the answer to that.
Indeed:
$ find .
.
./projects
./projects/foo
./projects/foo/chroot
find: File system loop detected; `./projects/foo/chroot/scratch' is
part of the same file system loop as `.'.
./projects/bar
./projects/bar/foo
./baz
find has some way of detecting such cases, but it doesn't do it via
any special syscalls, nor does the newfstatat(AT_SYMLINK_NOFOLLOW)
call it does return an error. And it does it regardless of whether
the -xdev option is specified or not. So it must have some form of
internal logic for detecting such loopy filesystem constructs.
However, operations such as "chmod -R" do *not* detect this
situation:
$ sudo chown -R -v dave:dave *
ownership of `baz' retained as dave:dave
changed ownership of `projects/foo/chroot/scratch/projects/foo/chroot/scratch' to dave:dave
changed ownership of `projects/foo/chroot/scratch/projects/foo/chroot' to dave:dave
changed ownership of `projects/foo/chroot/scratch/projects/foo' to dave:dave
changed ownership of `projects/foo/chroot/scratch/projects/bar/foo' to dave:dave
changed ownership of `projects/foo/chroot/scratch/projects/bar' to dave:dave
changed ownership of `projects/foo/chroot/scratch/projects' to dave:dave
ownership of `projects/foo/chroot/scratch/baz' retained as dave:dave
changed ownership of `projects/foo/chroot/scratch' to dave:dave
changed ownership of `projects/foo/chroot' to dave:dave
changed ownership of `projects/foo' to dave:dave
ownership of `projects/bar/foo' retained as dave:dave
ownership of `projects/bar' retained as dave:dave
changed ownership of `projects' to dave:dave
It's totally unclear what the behaviour of xfs_quota should be,
because operations that change user and group quotas are completely
ignorant of bind mounts.
So if we decide bind mounts are important to detect, the second
question is how do we detect bind mount point traversals in a
reliable manner that doesn't involve adding significant overhead to
the directory traversal code? I don't know the answer to that,
either, and if you care about this enough I guess you'll go and look
up what find does and tell us about it ;)
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-07-08 3:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-07 20:46 xfs_quota: bug: traverses bind mountpoints Paul Nienaber
2011-07-08 3:23 ` Dave Chinner [this message]
2011-07-08 4:48 ` Paul Nienaber
2011-07-08 8:01 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110708032351.GF1026@dastard \
--to=david@fromorbit.com \
--cc=phox@uvic.ca \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox