On Fri, 19 Feb 2010 02:34:29 -0700, Andreas Dilger <adilger@xxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
