[PATCH] VFS: new fgetattr() file operation

[PATCH] VFS: new fgetattr() file operation

[Miklos Szeredi]

I don't think Christoph will like the patch better, regardless of how
I change the description.

Of course, I'm open to suggestion on how to improve the interface, but
I think fundamentally this is the only way to correctly deal with the
below problem.

Anyway, here's the patch another time, please consider adding it to
-mm.  For 2.6.25 obviously.

Thanks,
Miklos
----

From: Miklos Szeredi <mszeredi@suse.cz>

Add a new file operation: f_op->fgetattr(), that is invoked by
fstat().  Fall back to i_op->getattr() if it is not defined.

We need this because fstat() semantics can in some cases be better
implemented if the filesystem has the open file available.

Let's take the following example: we have a network filesystem, with
the server implemented as an unprivileged userspace process running on
a UNIX system (this is basically what sshfs does).

We want the filesystem to follow the familiar UNIX file semantics as
closely as possible.  If for example we have this sequence of events,
we still would like fstat to work correctly:

 1) file X is opened on client
 2) file X is renamed to Y on server
 3) fstat() is performed on open file descriptor on client

This is only possible if the filesystem server acutally uses fstat()
on a file descriptor obtained when the file was opened.  Which means,
the filesystem client needs a way to get this information from the
VFS.

Even if we assume, that the remote filesystem never changes, it is
difficult to implement open-unlink-fstat semantics correctly in the
client, without having this information.

Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
---

Index: linux/fs/stat.c
===================================================================
--- linux.orig/fs/stat.c	2007-10-24 11:59:46.000000000 +0200
+++ linux/fs/stat.c	2007-10-24 11:59:47.000000000 +0200
@@ -55,6 +55,33 @@ int vfs_getattr(struct vfsmount *mnt, st
 
 EXPORT_SYMBOL(vfs_getattr);
 
+/*
+ * Perform getattr on an open file
+ *
+ * Fall back to i_op->getattr (or generic_fillattr) if the filesystem
+ * doesn't define an f_op->fgetattr operation.
+ */
+static int vfs_fgetattr(struct file *file, struct kstat *stat)
+{
+	struct vfsmount *mnt = file->f_path.mnt;
+	struct dentry *dentry = file->f_path.dentry;
+	struct inode *inode = dentry->d_inode;
+	int retval;
+
+	retval = security_inode_getattr(mnt, dentry);
+	if (retval)
+		return retval;
+
+	if (file->f_op && file->f_op->fgetattr) {
+		return file->f_op->fgetattr(file, stat);
+	} else if (inode->i_op->getattr) {
+		return inode->i_op->getattr(mnt, dentry, stat);
+	} else {
+		generic_fillattr(inode, stat);
+		return 0;
+	}
+}
+
 int vfs_stat_fd(int dfd, char __user *name, struct kstat *stat)
 {
 	struct nameidata nd;
@@ -101,7 +128,7 @@ int vfs_fstat(unsigned int fd, struct ks
 	int error = -EBADF;
 
 	if (f) {
-		error = vfs_getattr(f->f_path.mnt, f->f_path.dentry, stat);
+		error = vfs_fgetattr(f, stat);
 		fput(f);
 	}
 	return error;
Index: linux/include/linux/fs.h
===================================================================
--- linux.orig/include/linux/fs.h	2007-10-24 11:59:46.000000000 +0200
+++ linux/include/linux/fs.h	2007-10-24 11:59:47.000000000 +0200
@@ -1195,6 +1195,7 @@ struct file_operations {
 	ssize_t (*splice_read)(struct file *, loff_t *, struct pipe_inode_info *, size_t, unsigned int);
 	int (*setlease)(struct file *, long, struct file_lock **);
 	int (*revoke)(struct file *, struct address_space *);
+	int (*fgetattr)(struct file *, struct kstat *);
 };
 
 struct inode_operations {
Index: linux/fs/fuse/file.c
===================================================================
--- linux.orig/fs/fuse/file.c	2007-10-24 11:59:46.000000000 +0200
+++ linux/fs/fuse/file.c	2007-10-24 12:01:00.000000000 +0200
@@ -871,6 +871,17 @@ static int fuse_file_flock(struct file *
 	return err;
 }
 
+static int fuse_file_fgetattr(struct file *file, struct kstat *stat)
+{
+	struct inode *inode = file->f_dentry->d_inode;
+	struct fuse_conn *fc = get_fuse_conn(inode);
+
+	if (!fuse_allow_task(fc, current))
+		return -EACCES;
+
+	return fuse_update_attributes(inode, stat, file, NULL);
+}
+
 static sector_t fuse_bmap(struct address_space *mapping, sector_t block)
 {
 	struct inode *inode = mapping->host;
@@ -920,6 +931,7 @@ static const struct file_operations fuse
 	.fsync		= fuse_fsync,
 	.lock		= fuse_file_lock,
 	.flock		= fuse_file_flock,
+	.fgetattr	= fuse_file_fgetattr,
 	.splice_read	= generic_file_splice_read,
 };
 
@@ -933,6 +945,7 @@ static const struct file_operations fuse
 	.fsync		= fuse_fsync,
 	.lock		= fuse_file_lock,
 	.flock		= fuse_file_flock,
+	.fgetattr	= fuse_file_fgetattr,
 	/* no mmap and splice_read */
 };
 

Re: [PATCH] VFS: new fgetattr() file operation

[Peter Staubach]

Miklos Szeredi wrote:
> I don't think Christoph will like the patch better, regardless of how
> I change the description.
>
> Of course, I'm open to suggestion on how to improve the interface, but
> I think fundamentally this is the only way to correctly deal with the
> below problem.
>
> Anyway, here's the patch another time, please consider adding it to
> -mm.  For 2.6.25 obviously.
>
> Thanks,
> Miklos
> ----
>
> From: Miklos Szeredi <mszeredi@suse.cz>
>
> Add a new file operation: f_op->fgetattr(), that is invoked by
> fstat().  Fall back to i_op->getattr() if it is not defined.
>
> We need this because fstat() semantics can in some cases be better
> implemented if the filesystem has the open file available.
>
> Let's take the following example: we have a network filesystem, with
> the server implemented as an unprivileged userspace process running on
> a UNIX system (this is basically what sshfs does).
>
> We want the filesystem to follow the familiar UNIX file semantics as
> closely as possible.  If for example we have this sequence of events,
> we still would like fstat to work correctly:
>
>  1) file X is opened on client
>  2) file X is renamed to Y on server
>  3) fstat() is performed on open file descriptor on client
>
> This is only possible if the filesystem server acutally uses fstat()
> on a file descriptor obtained when the file was opened.  Which means,
> the filesystem client needs a way to get this information from the
> VFS.
>
>   

This true iff the protocol that this mythical network file
system uses the name of the file on the server to actually
identify the file on the server.

Clearly, this is broken on many levels.  It can't handle
situations as described nor can it handle different instances
of the same filename being used.

This is why NFS, a network file system, does not use the filename
as part of the file handle.

Wouldn't you be better off by attempting to implement an "open
by ino" operation and an operation to get the generation count
for the file and then modifying the network protocol of interest
to use these as identifiers for the file to be manipulated?

I agree with Christoph on this one.  It is the wrong path.

       ps


> Even if we assume, that the remote filesystem never changes, it is
> difficult to implement open-unlink-fstat semantics correctly in the
> client, without having this information.
>
> Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
> ---
>
> Index: linux/fs/stat.c
> ===================================================================
> --- linux.orig/fs/stat.c	2007-10-24 11:59:46.000000000 +0200
> +++ linux/fs/stat.c	2007-10-24 11:59:47.000000000 +0200
> @@ -55,6 +55,33 @@ int vfs_getattr(struct vfsmount *mnt, st
>  
>  EXPORT_SYMBOL(vfs_getattr);
>  
> +/*
> + * Perform getattr on an open file
> + *
> + * Fall back to i_op->getattr (or generic_fillattr) if the filesystem
> + * doesn't define an f_op->fgetattr operation.
> + */
> +static int vfs_fgetattr(struct file *file, struct kstat *stat)
> +{
> +	struct vfsmount *mnt = file->f_path.mnt;
> +	struct dentry *dentry = file->f_path.dentry;
> +	struct inode *inode = dentry->d_inode;
> +	int retval;
> +
> +	retval = security_inode_getattr(mnt, dentry);
> +	if (retval)
> +		return retval;
> +
> +	if (file->f_op && file->f_op->fgetattr) {
> +		return file->f_op->fgetattr(file, stat);
> +	} else if (inode->i_op->getattr) {
> +		return inode->i_op->getattr(mnt, dentry, stat);
> +	} else {
> +		generic_fillattr(inode, stat);
> +		return 0;
> +	}
> +}
> +
>  int vfs_stat_fd(int dfd, char __user *name, struct kstat *stat)
>  {
>  	struct nameidata nd;
> @@ -101,7 +128,7 @@ int vfs_fstat(unsigned int fd, struct ks
>  	int error = -EBADF;
>  
>  	if (f) {
> -		error = vfs_getattr(f->f_path.mnt, f->f_path.dentry, stat);
> +		error = vfs_fgetattr(f, stat);
>  		fput(f);
>  	}
>  	return error;
> Index: linux/include/linux/fs.h
> ===================================================================
> --- linux.orig/include/linux/fs.h	2007-10-24 11:59:46.000000000 +0200
> +++ linux/include/linux/fs.h	2007-10-24 11:59:47.000000000 +0200
> @@ -1195,6 +1195,7 @@ struct file_operations {
>  	ssize_t (*splice_read)(struct file *, loff_t *, struct pipe_inode_info *, size_t, unsigned int);
>  	int (*setlease)(struct file *, long, struct file_lock **);
>  	int (*revoke)(struct file *, struct address_space *);
> +	int (*fgetattr)(struct file *, struct kstat *);
>  };
>  
>  struct inode_operations {
> Index: linux/fs/fuse/file.c
> ===================================================================
> --- linux.orig/fs/fuse/file.c	2007-10-24 11:59:46.000000000 +0200
> +++ linux/fs/fuse/file.c	2007-10-24 12:01:00.000000000 +0200
> @@ -871,6 +871,17 @@ static int fuse_file_flock(struct file *
>  	return err;
>  }
>  
> +static int fuse_file_fgetattr(struct file *file, struct kstat *stat)
> +{
> +	struct inode *inode = file->f_dentry->d_inode;
> +	struct fuse_conn *fc = get_fuse_conn(inode);
> +
> +	if (!fuse_allow_task(fc, current))
> +		return -EACCES;
> +
> +	return fuse_update_attributes(inode, stat, file, NULL);
> +}
> +
>  static sector_t fuse_bmap(struct address_space *mapping, sector_t block)
>  {
>  	struct inode *inode = mapping->host;
> @@ -920,6 +931,7 @@ static const struct file_operations fuse
>  	.fsync		= fuse_fsync,
>  	.lock		= fuse_file_lock,
>  	.flock		= fuse_file_flock,
> +	.fgetattr	= fuse_file_fgetattr,
>  	.splice_read	= generic_file_splice_read,
>  };
>  
> @@ -933,6 +945,7 @@ static const struct file_operations fuse
>  	.fsync		= fuse_fsync,
>  	.lock		= fuse_file_lock,
>  	.flock		= fuse_file_flock,
> +	.fgetattr	= fuse_file_fgetattr,
>  	/* no mmap and splice_read */
>  };
>  
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   

Re: [PATCH] VFS: new fgetattr() file operation

[Miklos Szeredi]

> Miklos Szeredi wrote:
> > I don't think Christoph will like the patch better, regardless of how
> > I change the description.
> >
> > Of course, I'm open to suggestion on how to improve the interface, but
> > I think fundamentally this is the only way to correctly deal with the
> > below problem.
> >
> > Anyway, here's the patch another time, please consider adding it to
> > -mm.  For 2.6.25 obviously.
> >
> > Thanks,
> > Miklos
> > ----
> >
> > From: Miklos Szeredi <mszeredi@suse.cz>
> >
> > Add a new file operation: f_op->fgetattr(), that is invoked by
> > fstat().  Fall back to i_op->getattr() if it is not defined.
> >
> > We need this because fstat() semantics can in some cases be better
> > implemented if the filesystem has the open file available.
> >
> > Let's take the following example: we have a network filesystem, with
> > the server implemented as an unprivileged userspace process running on
> > a UNIX system (this is basically what sshfs does).
> >
> > We want the filesystem to follow the familiar UNIX file semantics as
> > closely as possible.  If for example we have this sequence of events,
> > we still would like fstat to work correctly:
> >
> >  1) file X is opened on client
> >  2) file X is renamed to Y on server
> >  3) fstat() is performed on open file descriptor on client
> >
> > This is only possible if the filesystem server acutally uses fstat()
> > on a file descriptor obtained when the file was opened.  Which means,
> > the filesystem client needs a way to get this information from the
> > VFS.
> >
> >   
> 
> This true iff the protocol that this mythical

Not mythical at all.  As noted in the description, there's sshfs, a
live and quite popular example of this sort of filesystem.

> network file system uses the name of the file on the server to
> actually identify the file on the server.

The constraint is that the server has to be an ordinary unprivileged
process.  How should it identify the file, other than by name, or by
an open file descriptor?

> Clearly, this is broken on many levels.  It can't handle
> situations as described nor can it handle different instances
> of the same filename being used.

Can you please give concrete examples what it can't handle, and how
should the implementation be improved to be able to handle it, given
the above constraints?

> This is why NFS, a network file system, does not use the filename
> as part of the file handle.

And the nfs server isn't a userspace process, or if it is, it must use
horrible hacks to convert the file handle to a name, that don't work
half the time.

> Wouldn't you be better off by attempting to implement an "open
> by ino" operation and an operation to get the generation count
> for the file and then modifying the network protocol of interest
> to use these as identifiers for the file to be manipulated?

You mean an "open by inode" on the userspace API?  My guess, it
wouldn't get very far.

Anyway, that would still not work on old servers, and servers running
other OS's.

Note, the point is _not_ to make a brand new NFS replacement
filesystem, that can use names instead of file handles.  The point is
to use existing infrastructure, to make the setup as easy as ssh'ing
to a different machine.  And sshfs does just that.

Miklos

Re: [PATCH] VFS: new fgetattr() file operation

[Peter Staubach]

Miklos Szeredi wrote:
>> Miklos Szeredi wrote:
>>     
>>> I don't think Christoph will like the patch better, regardless of how
>>> I change the description.
>>>
>>> Of course, I'm open to suggestion on how to improve the interface, but
>>> I think fundamentally this is the only way to correctly deal with the
>>> below problem.
>>>
>>> Anyway, here's the patch another time, please consider adding it to
>>> -mm.  For 2.6.25 obviously.
>>>
>>> Thanks,
>>> Miklos
>>> ----
>>>
>>> From: Miklos Szeredi <mszeredi@suse.cz>
>>>
>>> Add a new file operation: f_op->fgetattr(), that is invoked by
>>> fstat().  Fall back to i_op->getattr() if it is not defined.
>>>
>>> We need this because fstat() semantics can in some cases be better
>>> implemented if the filesystem has the open file available.
>>>
>>> Let's take the following example: we have a network filesystem, with
>>> the server implemented as an unprivileged userspace process running on
>>> a UNIX system (this is basically what sshfs does).
>>>
>>> We want the filesystem to follow the familiar UNIX file semantics as
>>> closely as possible.  If for example we have this sequence of events,
>>> we still would like fstat to work correctly:
>>>
>>>  1) file X is opened on client
>>>  2) file X is renamed to Y on server
>>>  3) fstat() is performed on open file descriptor on client
>>>
>>> This is only possible if the filesystem server acutally uses fstat()
>>> on a file descriptor obtained when the file was opened.  Which means,
>>> the filesystem client needs a way to get this information from the
>>> VFS.
>>>
>>>   
>>>       
>> This true iff the protocol that this mythical
>>     
>
> Not mythical at all.  As noted in the description, there's sshfs, a
> live and quite popular example of this sort of filesystem.
>
>   
>> network file system uses the name of the file on the server to
>> actually identify the file on the server.
>>     
>
> The constraint is that the server has to be an ordinary unprivileged
> process.  How should it identify the file, other than by name, or by
> an open file descriptor?
>
>   

I explained this.  The fileid and the generation count along
with the file system id will uniquely identify the file.

>> Clearly, this is broken on many levels.  It can't handle
>> situations as described nor can it handle different instances
>> of the same filename being used.
>>     
>
> Can you please give concrete examples what it can't handle, and how
> should the implementation be improved to be able to handle it, given
> the above constraints?
>
>   
>> This is why NFS, a network file system, does not use the filename
>> as part of the file handle.
>>     
>
> And the nfs server isn't a userspace process, or if it is, it must use
> horrible hacks to convert the file handle to a name, that don't work
> half the time.
>
>   

Nice try.  Wrong.  Try a different rationalization.

>> Wouldn't you be better off by attempting to implement an "open
>> by ino" operation and an operation to get the generation count
>> for the file and then modifying the network protocol of interest
>> to use these as identifiers for the file to be manipulated?
>>     
>
> You mean an "open by inode" on the userspace API?  My guess, it
> wouldn't get very far.
>
>   

This isn't a new idea and has been implemented on a variety of
different systems.

> Anyway, that would still not work on old servers, and servers running
> other OS's.
>
>   

I didn't think that we were talking about old servers and other
OS's.  My concern at the moment is Linux and the changes being
made to it.

> Note, the point is _not_ to make a brand new NFS replacement
> filesystem, that can use names instead of file handles.  The point is
> to use existing infrastructure, to make the setup as easy as ssh'ing
> to a different machine.  And sshfs does just that.

And the solution is limiting.  It is not scalable nor particularly
interesting to anyone interested in security.  Unless there is a
way of limiting access to a particular set of files, then it is
not generally useful outside of hackers or perhaps small groups
of users not concerned about too many aspects of security.

I am not interested in an extended discussion of this topic.

    Thanx...

       ps

Re: [PATCH] VFS: new fgetattr() file operation

[Miklos Szeredi]

> > The constraint is that the server has to be an ordinary unprivileged
> > process.  How should it identify the file, other than by name, or by
> > an open file descriptor?
> >
> >   
> 
> I explained this.  The fileid and the generation count along
> with the file system id will uniquely identify the file.

Yes, those filesystems, which have a file ID that can be used to index
the inodes.  Lot of filesystems (mostly those not originating from
UNIX) don't have such an ID.

> >> Clearly, this is broken on many levels.  It can't handle
> >> situations as described nor can it handle different instances
> >> of the same filename being used.
> >>     
> >
> > Can you please give concrete examples what it can't handle, and how
> > should the implementation be improved to be able to handle it, given
> > the above constraints?
> >
> >   
> >> This is why NFS, a network file system, does not use the filename
> >> as part of the file handle.
> >>     
> >
> > And the nfs server isn't a userspace process, or if it is, it must use
> > horrible hacks to convert the file handle to a name, that don't work
> > half the time.
> >
> >   
> 
> Nice try.  Wrong.  Try a different rationalization.

What's wrong with it?

> >> Wouldn't you be better off by attempting to implement an "open
> >> by ino" operation and an operation to get the generation count
> >> for the file and then modifying the network protocol of interest
> >> to use these as identifiers for the file to be manipulated?
> >>     
> >
> > You mean an "open by inode" on the userspace API?  My guess, it
> > wouldn't get very far.
> >
> >   
> 
> This isn't a new idea and has been implemented on a variety of
> different systems.

Like?

> > Anyway, that would still not work on old servers, and servers running
> > other OS's.
> >
> >   
> 
> I didn't think that we were talking about old servers and other
> OS's.  My concern at the moment is Linux and the changes being
> made to it.

In what way does passing the open file to the filesystem for the
fstat() syscall negatively impact Linux?

Usually it is best to design midlayers, so that they do the minimal
stuff, and pass the maximum of information to the low-layer, and
providing helper functions that the low-layer doesn't want to do
anything special.  Hiding information from the low-layer is pointless.

> > Note, the point is _not_ to make a brand new NFS replacement
> > filesystem, that can use names instead of file handles.  The point is
> > to use existing infrastructure, to make the setup as easy as ssh'ing
> > to a different machine.  And sshfs does just that.
> 
> And the solution is limiting.  It is not scalable nor particularly
> interesting to anyone interested in security.  Unless there is a
> way of limiting access to a particular set of files, then it is
> not generally useful outside of hackers or perhaps small groups
> of users not concerned about too many aspects of security.

I'm not sure what you are talking about here.  AFAICS this change
has absolutely nothing to do with filesystem (or any other kind of)
security.

> I am not interested in an extended discussion of this topic.

No problem.  Thanks anyway for your comments.

Miklos

Re: [PATCH] VFS: new fgetattr() file operation

[David Chinner]

On Wed, Oct 24, 2007 at 05:27:04PM +0200, Miklos Szeredi wrote:
> > >> Wouldn't you be better off by attempting to implement an "open
> > >> by ino" operation and an operation to get the generation count
> > >> for the file and then modifying the network protocol of interest
> > >> to use these as identifiers for the file to be manipulated?
> > >>     
> > >
> > > You mean an "open by inode" on the userspace API?  My guess, it
> > > wouldn't get very far.
> > 
> > This isn't a new idea and has been implemented on a variety of
> > different systems.
> 
> Like?

XFS.

'man open_by_handle'

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

Re: [PATCH] VFS: new fgetattr() file operation

[Miklos Szeredi]

> On Wed, Oct 24, 2007 at 05:27:04PM +0200, Miklos Szeredi wrote:
> > > >> Wouldn't you be better off by attempting to implement an "open
> > > >> by ino" operation and an operation to get the generation count
> > > >> for the file and then modifying the network protocol of interest
> > > >> to use these as identifiers for the file to be manipulated?
> > > >>     
> > > >
> > > > You mean an "open by inode" on the userspace API?  My guess, it
> > > > wouldn't get very far.
> > > 
> > > This isn't a new idea and has been implemented on a variety of
> > > different systems.
> > 
> > Like?
> 
> XFS.
> 
> 'man open_by_handle'

Doesn't seem widely used, with 600 something google hits.  And in this
old thread Linus is not entirely enthusiastic about the concept:

  http://lkml.org/lkml/1999/1/11/244

Miklos

Re: [PATCH] VFS: new fgetattr() file operation

[David Chinner]

On Fri, Oct 26, 2007 at 01:10:14AM +0200, Miklos Szeredi wrote:
> > On Wed, Oct 24, 2007 at 05:27:04PM +0200, Miklos Szeredi wrote:
> > > > >> Wouldn't you be better off by attempting to implement an "open
> > > > >> by ino" operation and an operation to get the generation count
> > > > >> for the file and then modifying the network protocol of interest
> > > > >> to use these as identifiers for the file to be manipulated?
> > > > >>     
> > > > >
> > > > > You mean an "open by inode" on the userspace API?  My guess, it
> > > > > wouldn't get very far.
> > > > 
> > > > This isn't a new idea and has been implemented on a variety of
> > > > different systems.
> > > 
> > > Like?
> > 
> > XFS.
> > 
> > 'man open_by_handle'
> 
> Doesn't seem widely used, with 600 something google hits.

from the man page:

"They are intended  for  use  by a limited set of system utilities such
as backup programs."

It also gets used by HSMs and so it is current, tested and is not
going away....

> And in this
> old thread Linus is not entirely enthusiastic about the concept:
> 
>   http://lkml.org/lkml/1999/1/11/244

That was "open by inode number", AFAICT. A handle is an opaque
blob that can be an arbitrary length defined by the filesystem.
You have to convert a fd or path to a handle first before you can
use it later, so any filesystem can implement it...

i.e. it is exactly what this (unanswered) post suggested:

http://lkml.org/lkml/1999/1/13/186

Just my 2c worth....

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

Re: [PATCH] VFS: new fgetattr() file operation

[Miklos Szeredi]

> On Fri, Oct 26, 2007 at 01:10:14AM +0200, Miklos Szeredi wrote:
> > > On Wed, Oct 24, 2007 at 05:27:04PM +0200, Miklos Szeredi wrote:
> > > > > >> Wouldn't you be better off by attempting to implement an "open
> > > > > >> by ino" operation and an operation to get the generation count
> > > > > >> for the file and then modifying the network protocol of interest
> > > > > >> to use these as identifiers for the file to be manipulated?
> > > > > >>     
> > > > > >
> > > > > > You mean an "open by inode" on the userspace API?  My guess, it
> > > > > > wouldn't get very far.
> > > > > 
> > > > > This isn't a new idea and has been implemented on a variety of
> > > > > different systems.
> > > > 
> > > > Like?
> > > 
> > > XFS.
> > > 
> > > 'man open_by_handle'
> > 
> > Doesn't seem widely used, with 600 something google hits.
> 
> from the man page:
> 
> "They are intended  for  use  by a limited set of system utilities such
> as backup programs."
> 
> It also gets used by HSMs and so it is current, tested and is not
> going away....

Sure.

> > And in this
> > old thread Linus is not entirely enthusiastic about the concept:
> > 
> >   http://lkml.org/lkml/1999/1/11/244
> 
> That was "open by inode number", AFAICT. A handle is an opaque
> blob that can be an arbitrary length defined by the filesystem.
> You have to convert a fd or path to a handle first before you can
> use it later, so any filesystem can implement it...
> 
> i.e. it is exactly what this (unanswered) post suggested:
> 
> http://lkml.org/lkml/1999/1/13/186

Well, yeah, if a filesystem doesn't have a global index, the whole
path could just be stuffed into the handle.

But there's not much point in that, is there?  And because the
interface bypasses normal access checking on parent directories, it
has security implications, making it not generally useful.

Specifically, it is not useful for the "unprivileged file server" case
that Peter was suggesting.

Miklos