linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com>
To: Al Viro <viro@ZenIV.linux.org.uk>,
	Andreas Dilger <andreas.dilger@oracle.com>
Cc: Neil Brown <neilb@suse.de>, Christoph Hellwig <hch@infradead.org>,
	Jonathan Corbet <corbet@lwn.net>, Serge Hallyn <serue@us.ibm.com>,
	linux-fsdevel@vger.kernel.org, Steven French <sfrench@us.ibm.com>,
	Philippe Deniel <philippe.deniel@CEA.FR>,
	"linux-kernel\@vger.kernel.org Mailinglist"
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH -V7 3/9] vfs: Add name to file handle conversion support
Date: Fri, 14 May 2010 23:48:24 +0530	[thread overview]
Message-ID: <87d3wye49b.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <20100514172510.GU30031@ZenIV.linux.org.uk>

On Fri, 14 May 2010 18:25:10 +0100, Al Viro <viro@ZenIV.linux.org.uk> wrote:
> On Thu, May 13, 2010 at 04:54:11PM -0600, Andreas Dilger wrote:
> 
> > fd = 0 is a valid descriptor, though -1 is not.  I'd be OK with this, because it still means we can use the UUID to positively identify the filesystem (it would also avoid the need to do a by-UUID lookup in most cases, since the dirfd would already point to a filesystem and we can just compare the handle UUID with the UUID for that superblock.
> > 
> > The question is what to do if the UUID in the file handle does not match the filesystem that is passed via vfsmount?  It would seem that vfsmount is needed for determining the namespace and possibly disambiguating multiple mounts of snapshots with the same UUID.  Independent of that if the UUID is not matching the underlying filesystem that the vfsmount is pointing to the open should fail with -ESTALE.
> > 
> > If the UUID is not the same, then the chance that the inode/generation stored in the file handle are still useful is slim.  If someone is cloning the filesystem down to the inode number, then they can clone the UUID as well.
> > 
> > In summary, I'm OK with this approach.
> 
> I am not.  First of all, it relies on order of vfsmounts in the list to
> decide which one gets picked; as far as I'm concerned, that alone is enough
> to declare it bogus.  "Let's pick the random answer" is wrong outside of
> /dev/random and it's got way too little entropy for that use ;-)
> 
> What's more, there's absolutely nothing to stop you from having fsid -> fd
> cache in userland and populating it on demand from whatever means you are
> using to determine the mapping from fsid to fs.
> 
> IOW, NAK.

How about
sys_open_by_handle(int mountdirfd,
                  struct file_handle __user *ufh, int open_flag)

and we validate the UUID present in the file_handle by using mountdirfd
vfsmount. In otherwords we drop the UUID based vfsmount lookup, But
still add UUID as a part of file handle ?

-aneesh


  reply	other threads:[~2010-05-14 18:18 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-12 15:50 [PATCH -V7 0/8] Generic name to handle and open by handle syscalls Aneesh Kumar K.V
2010-05-12 15:50 ` [PATCH -V7 1/9] exportfs: Return the minimum required handle size Aneesh Kumar K.V
2010-05-12 15:50 ` [PATCH -V7 2/9] vfs: Add uuid based vfsmount lookup Aneesh Kumar K.V
2010-05-12 15:50 ` [PATCH -V7 3/9] vfs: Add name to file handle conversion support Aneesh Kumar K.V
2010-05-12 21:49   ` Andreas Dilger
2010-05-12 22:43     ` Neil Brown
2010-05-13  6:17       ` Aneesh Kumar K. V
2010-05-13  7:11         ` Neil Brown
2010-05-13  8:30           ` Andreas Dilger
2010-05-13  8:47             ` Neil Brown
2010-05-13 14:21             ` Aneesh Kumar K. V
2010-05-13 18:17               ` Aneesh Kumar K. V
2010-05-13 22:54                 ` Andreas Dilger
2010-05-14 17:25                   ` Al Viro
2010-05-14 18:18                     ` Aneesh Kumar K. V [this message]
2010-05-14 18:40                       ` Al Viro
2010-05-15  5:31                         ` Aneesh Kumar K. V
2010-05-15  6:00                           ` Al Viro
2010-05-15 15:28                             ` Aneesh Kumar K. V
2010-05-13  0:20     ` Dave Chinner
2010-05-13  6:23       ` Aneesh Kumar K. V
2010-05-13  7:31         ` Dave Chinner
2010-05-13  5:56     ` Aneesh Kumar K. V
2010-05-13 14:24     ` Aneesh Kumar K. V
2010-05-12 15:50 ` [PATCH -V7 4/9] vfs: Add open by file handle support Aneesh Kumar K.V
2010-05-12 23:44   ` Neil Brown
2010-05-13  6:09     ` Dave Chinner
2010-05-13  6:37       ` Aneesh Kumar K. V
2010-05-14 10:41         ` Dave Chinner
2010-05-12 15:50 ` [PATCH -V7 5/9] vfs: Add freadlink syscall Aneesh Kumar K.V
2010-05-13  1:43   ` Neil Brown
2010-05-13  6:25     ` Aneesh Kumar K. V
2010-05-13  6:56       ` Neil Brown
2010-05-13  7:34         ` Aneesh Kumar K. V
2010-05-13  8:09           ` Neil Brown
2010-05-14 11:18         ` Aneesh Kumar K. V
2010-05-12 15:50 ` [PATCH -V7 6/9] ext4: Add get_fsid callback Aneesh Kumar K.V
2010-05-13  3:11   ` Dave Chinner
2010-05-13  6:32     ` Aneesh Kumar K. V
2010-05-14  1:44       ` Dave Chinner
2010-05-15  6:09         ` Aneesh Kumar K. V
2010-05-14 17:32   ` Coly Li
2010-05-14 18:21     ` Aneesh Kumar K. V
2010-05-14 19:08       ` Coly Li
2010-05-12 15:50 ` [PATCH -V7 7/9] x86: Add new syscalls for x86_32 Aneesh Kumar K.V
2010-05-12 15:50 ` [PATCH -V7 8/9] x86: Add new syscalls for x86_64 Aneesh Kumar K.V
2010-05-12 15:50 ` [PATCH -V7 9/9] ext3: Add get_fsid callback Aneesh Kumar K.V

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=87d3wye49b.fsf@linux.vnet.ibm.com \
    --to=aneesh.kumar@linux.vnet.ibm.com \
    --cc=andreas.dilger@oracle.com \
    --cc=corbet@lwn.net \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=philippe.deniel@CEA.FR \
    --cc=serue@us.ibm.com \
    --cc=sfrench@us.ibm.com \
    --cc=viro@ZenIV.linux.org.uk \
    /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;
as well as URLs for NNTP newsgroup(s).