Re: [RFC PATCH] Generic name to handle and open by handle syscalls

["Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com>]

On Fri, 19 Feb 2010 02:34:29 -0700, Andreas Dilger <adilger@sun.com> wrote:
> On 2010-02-18, at 22:42, Aneesh Kumar K.V wrote:
> > The below set of patches implement open by handle support using  
> > exportfs
> > operations. This allows user space application to map a file name to  
> > file
> > handle and later open the file using handle. This should be usable
> > for userspace NFS and 9P server. XFS already support this with the  
> > ioctls
> > XFS_IOC_PATH_TO_HANDLE and XFS_IOC_OPEN_BY_HANDLE.
> >
> > struct file_handle {
> > 	int handle_size;
> > 	int handle_type;
> > 	void *f_handle;
> > };
> 
> What is the required size of the f_handle field?  It seems that either  
> this
> should be a well-defined structure size in the header, or the syscall  
> will return an error like EOVERFLOW if the handle will not fit into  
> the supplied handle_size, and it returns the required size in  
> handle_size.


The patch already does that. I have made the syscall return with
-EAGAIN with handle_size containing the required value. May be
EOVERFLOW is the right error value. I will update in the next iteration.



> 
> > 	fh.handle_type = 0;
> > 	fh.handle = malloc(100);
> > 	fh.handle_size = 100/sizeof(int);
> 
> It seems strange to define the handle_size in terms of ints instead of  
> bytes?

If we agree with size in bytes. I can update the kernel to work in bytes.

> 
> > 	ret = syscall(338, argv[1], &fh);
> > 	fd = syscall(339, &fh, O_RDONLY);
> 
> What is the expected lifespan of "fh" to remain valid in the kernel?   
> Presumably this is not just the encoding of the inode number into a  
> buffer, or it would be too easy to forge from userspace.  That means  
> there needs to be some unguessable state in the kernel for each file  
> handle, that may potentially need to be kept indefinitely if there is  
> no expiry.
> 
> Will "fh" be portable between processes?  I assume that is the intent,  
> but good to declare the actual semantics of the syscalls before they  
> go into the kernel.

Life time rule and uniqueness rule should be same as the NFS file
handle. My understanding is there is no expiry. I am not sure what
would be the issues if one could guess the file handle ? It should
be looked at as another way to identify a file. The open call takes
the mode and normal permissions checks are done during open. 

If you are worried about limiting file access by controlling the
permissions of directories i guess the below mail explained that
we cannot depend on directory permissions for such access restrictions
http://article.gmane.org/gmane.linux.file-systems/37419 ?

-aneesh