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

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

[Aneesh Kumar K.V]

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.

Example program:
-------------
#include <stdio.h>
#include <stdlib.h>

#include <fcntl.h>
#include <unistd.h>
#include <errno.h>

struct file_handle {
	int handle_size;
	int handle_type;
	void *f_handle;
};
int main(int argc, char *argv[])
{
	int ret;
	int fd;
	char buf[100];
	struct file_handle fh;
	fh.handle_type = 0;
	fh.handle = malloc(100);
	fh.handle_size = 100/sizeof(int);
	errno  = 0;
	ret = syscall(338, argv[1], &fh);
	if (ret) {
		perror("Error:");
		exit(1);
	}
	printf("%d\n",fh.handle_size);
	fd = syscall(339, &fh, O_RDONLY);
	if (fd <= 0 ) {
		perror("Error:");
		exit(1);
	}
	printf("fd = %d\n", fd);
	memset(buf, 0 , 100);
	while (read(fd, buf, 100) > 0) {
		printf("%s", buf);
		memset(buf, 0 , 100);
	}
	return 0;
}

-aneesh

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

[Andreas Dilger]

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.

> 	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?

> 	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.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

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

[Aneesh Kumar K. V]

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
 

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

[Andreas Dilger]

On 2010-02-19, at 02:49, Aneesh Kumar K. V wrote:
> On Fri, 19 Feb 2010 02:34:29 -0700, Andreas Dilger <adilger@sun.com>  
> wrote:
>>
>> 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.

Yes, and NFS file handles can be a pain in the ass, because it means  
inode numbers/devices/fsid should never be changed for fear of  
breaking NFS.  I'd much rather advertise that handles have a limited  
lifespan (e.g. at most until the server reboots, possibly sooner) so  
that there isn't an expectation of them lasting forever.

> 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 
>  ?


I don't think one person's opinion circumvents many years of POSIX  
behaviour that the only way to access a file is to do path traversal  
and have permission all the way down.  It is one thing for a process  
with access to the file to get a file handle and pass it to another  
process (that can happen today already), but it definitely shouldn't  
be possible for an arbitrary process to invent a file handle and get  
access to a file to which it cannot do path traversal through any  
existing path.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

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

[Aneesh Kumar K. V]

On Sat, 20 Feb 2010 12:01:38 -0700, Andreas Dilger <adilger@sun.com> wrote:
> On 2010-02-19, at 02:49, Aneesh Kumar K. V wrote:
> > On Fri, 19 Feb 2010 02:34:29 -0700, Andreas Dilger <adilger@sun.com>  
> > wrote:
> >>
> >> 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.
> 
> Yes, and NFS file handles can be a pain in the ass, because it means  
> inode numbers/devices/fsid should never be changed for fear of  
> breaking NFS.  I'd much rather advertise that handles have a limited  
> lifespan (e.g. at most until the server reboots, possibly sooner) so  
> that there isn't an expectation of them lasting forever.

That will make the interface not useful for applications like user
space NFS server right ?  Most of them want server to map the handle
to an inode even after a server crash right. The crash recovery might
be done in case of these network file system with the above assumptions.

-aneesh

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

[Jonathan Corbet]

On Fri, 19 Feb 2010 11:12:26 +0530
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:

> The below set of patches implement open by handle support using exportfs
> operations.

I have a couple of questions...starting with: what is the use case for
this functionality?  There must, clearly, be some kind of application
which needs to be able to open by file handle, but I'm not sure what
that would be.

I agree with Andreas that the handle length looks like a bit of a
crapshoot.  How should an application developer know how much memory to
dedicate to this?

In do_sys_name_to_handle() you have:

> +	f_handle = kmalloc(handle_size, GFP_KERNEL);

handle_size comes directly from user space.  Perhaps it should be
sanity-checked?  (I would also just use handle->handle_size; later
handle_size contains the *real* handle size, and I found that confusing.
Yes, I'm easily confused, but...)

> +	handle->handle_type = retval;
> +	if (handle_size < handle->handle_size) {
> +		if (copy_to_user(handle->f_handle, f_handle,
> +					handle_size*sizeof(u32)))
> +			retval = -EFAULT;
> +		retval = 0;
> +	} else
> +		retval = -EAGAIN;
> +	handle->handle_size = handle_size;

EAGAIN seems like a strange thing to return here.  ENOSPC maybe?

Are you missing an "else" before the "retval = 0;" line?  You'll never
return -EFAULT here.

In do_sys_open_by_handle():

> +	if (!capable(CAP_SYS_ADMIN))
> +		/* Allow open by handle only by sysadmin */
> +		return -EPERM;

I assume this is to avoid access to readable files within unreadable
directories?   Otherwise you could check the permissions of the target
dentry.

CAP_SYS_ADMIN seems like the wrong capability, though.  CAP_DAC_OVERRIDE
might make more sense?

Is there any sense in allowing anybody to call name_to_handle() if
open_by_handle() is restricted?

Thanks,

jon

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

[James Morris]

[Adding LSM to the cc list...]


On Mon, 22 Feb 2010, Jonathan Corbet wrote:

> On Fri, 19 Feb 2010 11:12:26 +0530
> "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:
> 
> > The below set of patches implement open by handle support using exportfs
> > operations.
> 
> I have a couple of questions...starting with: what is the use case for
> this functionality?  There must, clearly, be some kind of application
> which needs to be able to open by file handle, but I'm not sure what
> that would be.
> 
> I agree with Andreas that the handle length looks like a bit of a
> crapshoot.  How should an application developer know how much memory to
> dedicate to this?
> 
> In do_sys_name_to_handle() you have:
> 
> > +	f_handle = kmalloc(handle_size, GFP_KERNEL);
> 
> handle_size comes directly from user space.  Perhaps it should be
> sanity-checked?  (I would also just use handle->handle_size; later
> handle_size contains the *real* handle size, and I found that confusing.
> Yes, I'm easily confused, but...)
> 
> > +	handle->handle_type = retval;
> > +	if (handle_size < handle->handle_size) {
> > +		if (copy_to_user(handle->f_handle, f_handle,
> > +					handle_size*sizeof(u32)))
> > +			retval = -EFAULT;
> > +		retval = 0;
> > +	} else
> > +		retval = -EAGAIN;
> > +	handle->handle_size = handle_size;
> 
> EAGAIN seems like a strange thing to return here.  ENOSPC maybe?
> 
> Are you missing an "else" before the "retval = 0;" line?  You'll never
> return -EFAULT here.
> 
> In do_sys_open_by_handle():
> 
> > +	if (!capable(CAP_SYS_ADMIN))
> > +		/* Allow open by handle only by sysadmin */
> > +		return -EPERM;
> 
> I assume this is to avoid access to readable files within unreadable
> directories?   Otherwise you could check the permissions of the target
> dentry.
> 
> CAP_SYS_ADMIN seems like the wrong capability, though.  CAP_DAC_OVERRIDE
> might make more sense?
> 
> Is there any sense in allowing anybody to call name_to_handle() if
> open_by_handle() is restricted?
> 
> Thanks,
> 
> jon
> --
> 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
> 

-- 
James Morris
<jmorris@namei.org>

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

[Aneesh Kumar K. V]

On Mon, 22 Feb 2010 16:06:59 -0700, Jonathan Corbet <corbet@lwn.net> wrote:
> On Fri, 19 Feb 2010 11:12:26 +0530
> "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:
> 
> > The below set of patches implement open by handle support using exportfs
> > operations.
> 
> I have a couple of questions...starting with: what is the use case for
> this functionality?  There must, clearly, be some kind of application
> which needs to be able to open by file handle, but I'm not sure what
> that would be.
>

User space NFS server would be one example. Also if we want to NFS
export another network file system which have a user space server, that
would be another reason.

> I agree with Andreas that the handle length looks like a bit of a
> crapshoot.  How should an application developer know how much memory to
> dedicate to this?
> 
> In do_sys_name_to_handle() you have:
> 
> > +	f_handle = kmalloc(handle_size, GFP_KERNEL);
> 
> handle_size comes directly from user space.  Perhaps it should be
> sanity-checked?  (I would also just use handle->handle_size; later
> handle_size contains the *real* handle size, and I found that confusing.
> Yes, I'm easily confused, but...)

I already had a FIXME is another patch to sanity check the handle
size. I was not sure what should be maximum size. Andreas suggested 4096
So i will update the patch in the next iteration with that value. I will
also update the variable names as you suggested above.

> 
> > +	handle->handle_type = retval;
> > +	if (handle_size < handle->handle_size) {
> > +		if (copy_to_user(handle->f_handle, f_handle,
> > +					handle_size*sizeof(u32)))
> > +			retval = -EFAULT;
> > +		retval = 0;
> > +	} else
> > +		retval = -EAGAIN;
> > +	handle->handle_size = handle_size;
> 
> EAGAIN seems like a strange thing to return here.  ENOSPC maybe?

The reason for me using EAGAIN was to give a hint that if the user
reissue the call with new returned handle_size we should be ok. But
Andreas suggested EOVERFLOW. So i will use EOVERFLOW. Do you think
ENOSPC is he right error value here ?

> 
> Are you missing an "else" before the "retval = 0;" line?  You'll never
> return -EFAULT here.
> 

good catch. Will fix in the next iteration


> In do_sys_open_by_handle():
> 
> > +	if (!capable(CAP_SYS_ADMIN))
> > +		/* Allow open by handle only by sysadmin */
> > +		return -EPERM;
> 
> I assume this is to avoid access to readable files within unreadable
> directories?   Otherwise you could check the permissions of the target
> dentry.
> 
> CAP_SYS_ADMIN seems like the wrong capability, though.  CAP_DAC_OVERRIDE
> might make more sense?

I guess CAP_DAC_OVERRIDE should be enough here. The CAP_SYS_ADMIN
restriction came from the xfs ioctl version. 

> 
> Is there any sense in allowing anybody to call name_to_handle() if
> open_by_handle() is restricted?
> 

I guess it should still be useful because handle can be passed around
and later given to a process that have enough permission to open by handle.

-aneesh

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

[Jonathan Corbet]

On Tue, 23 Feb 2010 14:28:36 +0530
"Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com> wrote:

> > EAGAIN seems like a strange thing to return here.  ENOSPC maybe?  
> 
> The reason for me using EAGAIN was to give a hint that if the user
> reissue the call with new returned handle_size we should be ok. But
> Andreas suggested EOVERFLOW. So i will use EOVERFLOW. Do you think
> ENOSPC is he right error value here ?

EOVERFLOW is probably better than ENOSPC, I'd go with that.

jon

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

[Dave Chinner]

On Tue, Feb 23, 2010 at 02:28:36PM +0530, Aneesh Kumar K. V wrote:
> On Mon, 22 Feb 2010 16:06:59 -0700, Jonathan Corbet <corbet@lwn.net> wrote:
> > On Fri, 19 Feb 2010 11:12:26 +0530
> > "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:
> > 
> > > The below set of patches implement open by handle support using exportfs
> > > operations.
> > 
> > I have a couple of questions...starting with: what is the use case for
> > this functionality?  There must, clearly, be some kind of application
> > which needs to be able to open by file handle, but I'm not sure what
> > that would be.
> >
> 
> User space NFS server would be one example. Also if we want to NFS
> export another network file system which have a user space server, that
> would be another reason.

Some history - the XFS handle interface was once used for a
userspace NFS server on Irix. IIRC it was replaced by a kernel based
server in about 1995 because the syscall overhead was a
performance limiting factor and since then only XFS specific
applications have used the interface. OOC, does an up-to-date
userspace NFS server that could make use of this even exist today?

As it is, these days the XFS handle interface is not intended for
such a use. From the XFS libhandle manpage:

DESCRIPTION
       These functions provide a way to perform certain filesystem
       operations without using  a  file  descriptor  to  access
       filesystem objects.  They  are intended for use by a limited
       set of system utilities such as backup programs. They are
       supported only by the XFS filesystem.  Link with the
       libhandle library to access these functions.

i.e. it is intended to be used for tight integration of userspace
filesystem utilities into the filesystem.

As for example uses, the first is xfsdump and xfsrestore - XFS's
optimised backup and restore programs.  The second is DMF - SGI's
HSM that is built on top of XFS. Both of these could not do what
they do without the handle interface...

FWIW, These applications both require XFS's handles to be stable for the
life of an inode as well as unique across the system. Hence the
XFS handle contains a fsid and is stable across reboots.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

[Serge E. Hallyn]

Quoting Aneesh Kumar K. V (aneesh.kumar@linux.vnet.ibm.com):
> On Mon, 22 Feb 2010 16:06:59 -0700, Jonathan Corbet <corbet@lwn.net> wrote:
> > On Fri, 19 Feb 2010 11:12:26 +0530
> > "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:
> > 
> > > The below set of patches implement open by handle support using exportfs
> > > operations.
> > 
> > I have a couple of questions...starting with: what is the use case for
> > this functionality?  There must, clearly, be some kind of application
> > which needs to be able to open by file handle, but I'm not sure what
> > that would be.
> >
> 
> User space NFS server would be one example. Also if we want to NFS
> export another network file system which have a user space server, that
> would be another reason.
> 
> > I agree with Andreas that the handle length looks like a bit of a
> > crapshoot.  How should an application developer know how much memory to
> > dedicate to this?
> > 
> > In do_sys_name_to_handle() you have:
> > 
> > > +	f_handle = kmalloc(handle_size, GFP_KERNEL);
> > 
> > handle_size comes directly from user space.  Perhaps it should be
> > sanity-checked?  (I would also just use handle->handle_size; later
> > handle_size contains the *real* handle size, and I found that confusing.
> > Yes, I'm easily confused, but...)
> 
> I already had a FIXME is another patch to sanity check the handle
> size. I was not sure what should be maximum size. Andreas suggested 4096
> So i will update the patch in the next iteration with that value. I will
> also update the variable names as you suggested above.
> 
> > 
> > > +	handle->handle_type = retval;
> > > +	if (handle_size < handle->handle_size) {
> > > +		if (copy_to_user(handle->f_handle, f_handle,
> > > +					handle_size*sizeof(u32)))
> > > +			retval = -EFAULT;
> > > +		retval = 0;
> > > +	} else
> > > +		retval = -EAGAIN;
> > > +	handle->handle_size = handle_size;
> > 
> > EAGAIN seems like a strange thing to return here.  ENOSPC maybe?
> 
> The reason for me using EAGAIN was to give a hint that if the user
> reissue the call with new returned handle_size we should be ok. But
> Andreas suggested EOVERFLOW. So i will use EOVERFLOW. Do you think
> ENOSPC is he right error value here ?
> 
> > 
> > Are you missing an "else" before the "retval = 0;" line?  You'll never
> > return -EFAULT here.
> > 
> 
> good catch. Will fix in the next iteration
> 
> 
> > In do_sys_open_by_handle():
> > 
> > > +	if (!capable(CAP_SYS_ADMIN))
> > > +		/* Allow open by handle only by sysadmin */
> > > +		return -EPERM;
> > 
> > I assume this is to avoid access to readable files within unreadable
> > directories?   Otherwise you could check the permissions of the target
> > dentry.
> > 
> > CAP_SYS_ADMIN seems like the wrong capability, though.  CAP_DAC_OVERRIDE
> > might make more sense?
> 
> I guess CAP_DAC_OVERRIDE should be enough here. The CAP_SYS_ADMIN
> restriction came from the xfs ioctl version. 

I'd be curious to see the reasons for requiring it in the xfs version.
Do you have any docs about it?  You're still doing a dentry_open, and
you got the filename fd somehow so the name shouldn't be a secret...
An LSM hook - specifically to make sure that selinux still allows you
to read the path (access to file->f_security) - might belong here, but
I dunno about the capable check.

thanks,
-serge

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

[Jonathan Corbet]

On Wed, 24 Feb 2010 22:53:23 -0600
"Serge E. Hallyn" <serue@us.ibm.com> wrote:

> I'd be curious to see the reasons for requiring it in the xfs version.
> Do you have any docs about it?  You're still doing a dentry_open, and
> you got the filename fd somehow so the name shouldn't be a secret...
> An LSM hook - specifically to make sure that selinux still allows you
> to read the path (access to file->f_security) - might belong here,

I had assumed it was the path that was the issue; a file handle is
divorced from that path, so there's no way to know if a process can
search its way down to the file or not.  That would leave the system
open to the same "open the file after path permissions have changed"
problem that people have complained about in other contexts.  It seems
like you could also fish for files by opening random file handles; I
don't know how large the search space is, so it's hard for me to say
how practical that would be.

jon

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

[Serge E. Hallyn]

Quoting Jonathan Corbet (corbet@lwn.net):
> On Wed, 24 Feb 2010 22:53:23 -0600
> "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> 
> > I'd be curious to see the reasons for requiring it in the xfs version.
> > Do you have any docs about it?  You're still doing a dentry_open, and
> > you got the filename fd somehow so the name shouldn't be a secret...
> > An LSM hook - specifically to make sure that selinux still allows you
> > to read the path (access to file->f_security) - might belong here,
> 
> I had assumed it was the path that was the issue; a file handle is
> divorced from that path, so there's no way to know if a process can
> search its way down to the file or not.  That would leave the system
> open to the same "open the file after path permissions have changed"
> problem that people have complained about in other contexts.  It seems
> like you could also fish for files by opening random file handles; I
> don't know how large the search space is, so it's hard for me to say
> how practical that would be.

Right, and so I think what is really needed is some DAC checks at the
newly-introduced sys_name_to_handle(), which near as I could tell are
not there at all.

Then, if process X is going to sys_open_by_handle() using pathname
fd 4, then fd 4 had to be created using sys_name_to_handle() either
by X or by some process Y which handed fd 4 over to X.  In either
case, it's basically no different from a open_at() where the
directory fd was handed to X by Y at that point, right?

So, if do_sys_name_to_handle() actually does DAC checks (somewhere
in the depths of the exportfs code?) then all should be fine now.
But I don't see any...

-serge

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

[Aneesh Kumar K. V]

On Thu, 25 Feb 2010 09:19:09 -0600, "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> Quoting Jonathan Corbet (corbet@lwn.net):
> > On Wed, 24 Feb 2010 22:53:23 -0600
> > "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> > 
> > > I'd be curious to see the reasons for requiring it in the xfs version.
> > > Do you have any docs about it?  You're still doing a dentry_open, and
> > > you got the filename fd somehow so the name shouldn't be a secret...
> > > An LSM hook - specifically to make sure that selinux still allows you
> > > to read the path (access to file->f_security) - might belong here,
> > 
> > I had assumed it was the path that was the issue; a file handle is
> > divorced from that path, so there's no way to know if a process can
> > search its way down to the file or not.  That would leave the system
> > open to the same "open the file after path permissions have changed"
> > problem that people have complained about in other contexts.  It seems
> > like you could also fish for files by opening random file handles; I
> > don't know how large the search space is, so it's hard for me to say
> > how practical that would be.
> 
> Right, and so I think what is really needed is some DAC checks at the
> newly-introduced sys_name_to_handle(), which near as I could tell are
> not there at all.
> 
> Then, if process X is going to sys_open_by_handle() using pathname
> fd 4, then fd 4 had to be created using sys_name_to_handle() either
> by X or by some process Y which handed fd 4 over to X.  In either
> case, it's basically no different from a open_at() where the
> directory fd was handed to X by Y at that point, right?
> 
> So, if do_sys_name_to_handle() actually does DAC checks (somewhere
> in the depths of the exportfs code?) then all should be fine now.
> But I don't see any...


user_lpath(..) used to convert name to path does path look using normal
permission check. So we do check for permissions when converting a path
to handle. But the problem still remain with respect to somebody being
able to guess the file handle and use that in open_by_handle. Currently
open_by handle() is limited to CAP_SYS_ADMIN (which i am updating to
CAP_DAC_OVERRIDE). 

-aneesh

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

[Serge E. Hallyn]

Quoting Aneesh Kumar K. V (aneesh.kumar@linux.vnet.ibm.com):
> On Thu, 25 Feb 2010 09:19:09 -0600, "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> > Quoting Jonathan Corbet (corbet@lwn.net):
> > > On Wed, 24 Feb 2010 22:53:23 -0600
> > > "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> > > 
> > > > I'd be curious to see the reasons for requiring it in the xfs version.
> > > > Do you have any docs about it?  You're still doing a dentry_open, and
> > > > you got the filename fd somehow so the name shouldn't be a secret...
> > > > An LSM hook - specifically to make sure that selinux still allows you
> > > > to read the path (access to file->f_security) - might belong here,
> > > 
> > > I had assumed it was the path that was the issue; a file handle is
> > > divorced from that path, so there's no way to know if a process can
> > > search its way down to the file or not.  That would leave the system
> > > open to the same "open the file after path permissions have changed"
> > > problem that people have complained about in other contexts.  It seems
> > > like you could also fish for files by opening random file handles; I
> > > don't know how large the search space is, so it's hard for me to say
> > > how practical that would be.
> > 
> > Right, and so I think what is really needed is some DAC checks at the
> > newly-introduced sys_name_to_handle(), which near as I could tell are
> > not there at all.
> > 
> > Then, if process X is going to sys_open_by_handle() using pathname
> > fd 4, then fd 4 had to be created using sys_name_to_handle() either
> > by X or by some process Y which handed fd 4 over to X.  In either
> > case, it's basically no different from a open_at() where the
> > directory fd was handed to X by Y at that point, right?
> > 
> > So, if do_sys_name_to_handle() actually does DAC checks (somewhere
> > in the depths of the exportfs code?) then all should be fine now.
> > But I don't see any...
> 
> 
> user_lpath(..) used to convert name to path does path look using normal

Ah, there it is, thanks.

In that case I don't see where there is any reason for special
privilege on the part of a process who receives that fd.

Let me put it another way:  if task Y does sys_name_to_handle() to
create an fd, then we should not absolve Y of the responsibility of
not passing that fd around willy nilly by papering over
sys_open_by_handle() with a requirement for superuser privileges.

And if Y were intentionally misbehaving, then it could just share
the pathname in countless already-existing ways, and then just for
the heck of it open the file itself and pass that fd to the client.
So not allowing the pathname fd to be transferred seems worthless.

> permission check. So we do check for permissions when converting a path
> to handle. But the problem still remain with respect to somebody being
> able to guess the file handle and use that in open_by_handle. Currently

But why is that a problem?  I don't see how it can be abused by a user,
unless it is the specific intent for some server Y to create a pathname
fd FD and pass that to a client X, where X should be able to see the file
contents but not the pathname?  And if that were the case then you
wouldn't require CAP_SYS_ADMIN for the client.

I'm obviously missing something - can you give a specific example?

> open_by handle() is limited to CAP_SYS_ADMIN (which i am updating to
> CAP_DAC_OVERRIDE). 

-serge

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

[Aneesh Kumar K. V]

On Thu, 25 Feb 2010 12:11:13 -0600, "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> Quoting Aneesh Kumar K. V (aneesh.kumar@linux.vnet.ibm.com):
> > On Thu, 25 Feb 2010 09:19:09 -0600, "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> > > Quoting Jonathan Corbet (corbet@lwn.net):
> > > > On Wed, 24 Feb 2010 22:53:23 -0600
> > > > "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> > > > 
> > > > > I'd be curious to see the reasons for requiring it in the xfs version.
> > > > > Do you have any docs about it?  You're still doing a dentry_open, and
> > > > > you got the filename fd somehow so the name shouldn't be a secret...
> > > > > An LSM hook - specifically to make sure that selinux still allows you
> > > > > to read the path (access to file->f_security) - might belong here,
> > > > 
> > > > I had assumed it was the path that was the issue; a file handle is
> > > > divorced from that path, so there's no way to know if a process can
> > > > search its way down to the file or not.  That would leave the system
> > > > open to the same "open the file after path permissions have changed"
> > > > problem that people have complained about in other contexts.  It seems
> > > > like you could also fish for files by opening random file handles; I
> > > > don't know how large the search space is, so it's hard for me to say
> > > > how practical that would be.
> > > 
> > > Right, and so I think what is really needed is some DAC checks at the
> > > newly-introduced sys_name_to_handle(), which near as I could tell are
> > > not there at all.
> > > 
> > > Then, if process X is going to sys_open_by_handle() using pathname
> > > fd 4, then fd 4 had to be created using sys_name_to_handle() either
> > > by X or by some process Y which handed fd 4 over to X.  In either
> > > case, it's basically no different from a open_at() where the
> > > directory fd was handed to X by Y at that point, right?
> > > 
> > > So, if do_sys_name_to_handle() actually does DAC checks (somewhere
> > > in the depths of the exportfs code?) then all should be fine now.
> > > But I don't see any...
> > 
> > 
> > user_lpath(..) used to convert name to path does path look using normal
> 
> Ah, there it is, thanks.
> 
> In that case I don't see where there is any reason for special
> privilege on the part of a process who receives that fd.
> 
> Let me put it another way:  if task Y does sys_name_to_handle() to
> create an fd, then we should not absolve Y of the responsibility of
> not passing that fd around willy nilly by papering over
> sys_open_by_handle() with a requirement for superuser privileges.
> 
> And if Y were intentionally misbehaving, then it could just share
> the pathname in countless already-existing ways, and then just for
> the heck of it open the file itself and pass that fd to the client.
> So not allowing the pathname fd to be transferred seems worthless.
> 
> > permission check. So we do check for permissions when converting a path
> > to handle. But the problem still remain with respect to somebody being
> > able to guess the file handle and use that in open_by_handle. Currently
> 
> But why is that a problem?  I don't see how it can be abused by a user,
> unless it is the specific intent for some server Y to create a pathname
> fd FD and pass that to a client X, where X should be able to see the file
> contents but not the pathname?  And if that were the case then you
> wouldn't require CAP_SYS_ADMIN for the client.
> 
> I'm obviously missing something - can you give a specific example?

Currently whether a user is allowed to open a file is also determined by
the permission of the directory components of the path. That's denying
execute bits on the directory prevent the lookup and so user can't open
the file. (Whether we can depend on this behaviour is debated before).
With file handle being valid for the life of the file, if a user is able
to guess handle for file /a/b/c then he will be able to open 'c' without
looking at the execute bits of 'a' or 'b'.

-aneesh

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

[Serge E. Hallyn]

Quoting Aneesh Kumar K. V (aneesh.kumar@linux.vnet.ibm.com):
> On Thu, 25 Feb 2010 12:11:13 -0600, "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> > Quoting Aneesh Kumar K. V (aneesh.kumar@linux.vnet.ibm.com):
> > > On Thu, 25 Feb 2010 09:19:09 -0600, "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> > > > Quoting Jonathan Corbet (corbet@lwn.net):
> > > > > On Wed, 24 Feb 2010 22:53:23 -0600
> > > > > "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> > > > > 
> > > > > > I'd be curious to see the reasons for requiring it in the xfs version.
> > > > > > Do you have any docs about it?  You're still doing a dentry_open, and
> > > > > > you got the filename fd somehow so the name shouldn't be a secret...
> > > > > > An LSM hook - specifically to make sure that selinux still allows you
> > > > > > to read the path (access to file->f_security) - might belong here,
> > > > > 
> > > > > I had assumed it was the path that was the issue; a file handle is
> > > > > divorced from that path, so there's no way to know if a process can
> > > > > search its way down to the file or not.  That would leave the system
> > > > > open to the same "open the file after path permissions have changed"
> > > > > problem that people have complained about in other contexts.  It seems
> > > > > like you could also fish for files by opening random file handles; I
> > > > > don't know how large the search space is, so it's hard for me to say
> > > > > how practical that would be.
> > > > 
> > > > Right, and so I think what is really needed is some DAC checks at the
> > > > newly-introduced sys_name_to_handle(), which near as I could tell are
> > > > not there at all.
> > > > 
> > > > Then, if process X is going to sys_open_by_handle() using pathname
> > > > fd 4, then fd 4 had to be created using sys_name_to_handle() either
> > > > by X or by some process Y which handed fd 4 over to X.  In either
> > > > case, it's basically no different from a open_at() where the
> > > > directory fd was handed to X by Y at that point, right?
> > > > 
> > > > So, if do_sys_name_to_handle() actually does DAC checks (somewhere
> > > > in the depths of the exportfs code?) then all should be fine now.
> > > > But I don't see any...
> > > 
> > > 
> > > user_lpath(..) used to convert name to path does path look using normal
> > 
> > Ah, there it is, thanks.
> > 
> > In that case I don't see where there is any reason for special
> > privilege on the part of a process who receives that fd.
> > 
> > Let me put it another way:  if task Y does sys_name_to_handle() to
> > create an fd, then we should not absolve Y of the responsibility of
> > not passing that fd around willy nilly by papering over
> > sys_open_by_handle() with a requirement for superuser privileges.
> > 
> > And if Y were intentionally misbehaving, then it could just share
> > the pathname in countless already-existing ways, and then just for
> > the heck of it open the file itself and pass that fd to the client.
> > So not allowing the pathname fd to be transferred seems worthless.
> > 
> > > permission check. So we do check for permissions when converting a path
> > > to handle. But the problem still remain with respect to somebody being
> > > able to guess the file handle and use that in open_by_handle. Currently
> > 
> > But why is that a problem?  I don't see how it can be abused by a user,
> > unless it is the specific intent for some server Y to create a pathname
> > fd FD and pass that to a client X, where X should be able to see the file
> > contents but not the pathname?  And if that were the case then you
> > wouldn't require CAP_SYS_ADMIN for the client.
> > 
> > I'm obviously missing something - can you give a specific example?
> 
> Currently whether a user is allowed to open a file is also determined by
> the permission of the directory components of the path. That's denying
> execute bits on the directory prevent the lookup and so user can't open
> the file. (Whether we can depend on this behaviour is debated before).
> With file handle being valid for the life of the file, if a user is able
> to guess handle for file /a/b/c then he will be able to open 'c' without

Jipes!  I was misunderstanding what you were doing with the struct
file_handle.  Your use of the phrase 'guess handle for file' set me
straight.  I thought you were encoding a file_handle into an fd using
sys_name_to_handle(), and passing that fd along over a unix sock - so a
client would have to receive a validly opened fd to use it.  If it can
just guess at a string, then yeah, please do hide that behind as much
privilege as you can!

I take it then that the file_handles must be communicated over something
other than unix socks (else you could just pass an fd and let the client
either use the fd, or re-open /proc/self/fd/<fd>)?  Would you be able to
at least add a touch of randomness and hashing to make this sa[fn]er and
turn this into a single-use capability?  Or does that not fit your usage
model?  So the server would come up with some random bytes B, calculate
H = hash(F|B) (hash of filename concatenated with random bytes), pass F
and H along to client while storing F and B, so client can pass F and H
to sys_open_by_handle() which confirms that that was a valid file
handle?

thanks,
-serge

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

[Andreas Dilger]

On 2010-02-25, at 12:05, Serge E. Hallyn wrote:
> Jipes!  I was misunderstanding what you were doing with the struct
> file_handle.  Your use of the phrase 'guess handle for file' set me
> straight.  I thought you were encoding a file_handle into an fd using
> sys_name_to_handle(), and passing that fd along over a unix sock -  
> so a
> client would have to receive a validly opened fd to use it.  If it can
> just guess at a string, then yeah, please do hide that behind as much
> privilege as you can!

It seems to me that there are two different, though related, use  
cases.  In some cases it would be desirable to allow "short lived"  
handles to be passed between processes, and in other cases it is  
necessary to have "long lived" handles.

For "short lived" or "strong" handles they should contain a capability  
that prevents arbitrary handles from being guessed, so such a handle  
could be used by any process, possibly for at most a limited duration  
or use count.  For "long lived" handles, either the capability needs  
to be stored persistently so that it can be validated even after a  
server reboot, or the "weak" handles (without capabilities) that can  
be guessed should only be usable with CAP_DAC_OVERRIDE.

> I take it then that the file_handles must be communicated over  
> something
> other than unix socks (else you could just pass an fd and let the  
> client
> either use the fd, or re-open /proc/self/fd/<fd>)?  Would you be  
> able to
> at least add a touch of randomness and hashing to make this sa[fn]er  
> and
> turn this into a single-use capability?  Or does that not fit your  
> usage
> model?  So the server would come up with some random bytes B,  
> calculate
> H = hash(F|B) (hash of filename concatenated with random bytes),  
> pass F
> and H along to client while storing F and B, so client can pass F  
> and H
> to sys_open_by_handle() which confirms that that was a valid file
> handle?


Something like that.  I'm not a security expert, and capability  
designs exist and I'd suggest we don't try to invent anything here.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

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

[Serge E. Hallyn]

Quoting Andreas Dilger (adilger@sun.com):
> On 2010-02-25, at 12:05, Serge E. Hallyn wrote:
> >Jipes!  I was misunderstanding what you were doing with the struct
> >file_handle.  Your use of the phrase 'guess handle for file' set me
> >straight.  I thought you were encoding a file_handle into an fd using
> >sys_name_to_handle(), and passing that fd along over a unix sock -
> >so a
> >client would have to receive a validly opened fd to use it.  If it can
> >just guess at a string, then yeah, please do hide that behind as much
> >privilege as you can!
> 
> It seems to me that there are two different, though related, use
> cases.  In some cases it would be desirable to allow "short lived"
> handles to be passed between processes, and in other cases it is
> necessary to have "long lived" handles.

Yes, but what do the client and server sides look like?  Can this
be done using fds instead of file_handles?  I.e. is requiring they
be sent over a unix sock ok?  Probably not, but it seems worth
checking.

> For "short lived" or "strong" handles they should contain a
> capability that prevents arbitrary handles from being guessed, so
> such a handle could be used by any process, possibly for at most a
> limited duration or use count.  For "long lived" handles, either the
> capability needs to be stored persistently so that it can be
> validated even after a server reboot, or the "weak" handles (without
> capabilities) that can be guessed should only be usable with
> CAP_DAC_OVERRIDE.
> 
> >I take it then that the file_handles must be communicated over
> >something
> >other than unix socks (else you could just pass an fd and let the
> >client
> >either use the fd, or re-open /proc/self/fd/<fd>)?  Would you be
> >able to
> >at least add a touch of randomness and hashing to make this
> >sa[fn]er and
> >turn this into a single-use capability?  Or does that not fit your
> >usage
> >model?  So the server would come up with some random bytes B,
> >calculate
> >H = hash(F|B) (hash of filename concatenated with random bytes),
> >pass F
> >and H along to client while storing F and B, so client can pass F
> >and H
> >to sys_open_by_handle() which confirms that that was a valid file
> >handle?
> 
> 
> Something like that.  I'm not a security expert, and capability
> designs exist and I'd suggest we don't try to invent anything here.

All the better  :)

-serge

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

[DENIEL Philippe]

Hi,

I just found this message in this mailing list archive. This follows a
search I did after having a look at this thread on LWN.net
(http://lwn.net/Articles/375888/).

> 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.

After reading the mailing-list archive, it sounds like many people do
not see the benefit in having a way to address files from user space via
their fh and not only through the use of their name. I am leading a
project (see http://nfs-ganesha.sourceforge.net) that implements NFS
functionality from User Space. My server has various backends modules
that make it possible to address different kind of namespaces. When we
did the one dedicated to POSIX, we were strongly limited by the POSIX
functions that reference the files only by their names. We implemented
kind of "name <-> fh" tracking feature via the use of a db, but it is a
bit heavy and not performant. Having a way to translate name to fh, or
open file by fh would be great : it would make it possible to get rid of
all this heavy plumber we did with the db. In fact, half of the work is
already done in my project : we use LUSTRE a lot on our site, and we had
a need for exporting LUSTRE via NFS. There is a user space LUSTRE-API
was provide this "name to fid" and "open by fid" feature. We used it to
build a LUSTRE dedicated backend, and this fit perfectly our needs. So,
if patches are made to perform name-to-handle and open-by-handle
operation, this would be great. Of course, this is my personal point of
view, but personally I have a clear need of this feature.

Regards

Philippe