Re: openg and path_to_handle

[Rob Ross <rross@mcs.anl.gov>]

David Chinner wrote:
> On Wed, Dec 06, 2006 at 09:53:39AM -0600, Rob Ross wrote:
>> David Chinner wrote:
>>> On Tue, Dec 05, 2006 at 05:47:16PM +0100, Latchesar Ionkov wrote:
>>>> On 12/5/06, Rob Ross <rross@mcs.anl.gov> wrote:
>>>>> Hi,
>>>>>
>>>>> I agree that it is not feasible to add new system calls every time
>>>>> somebody has a problem, and we don't take adding system calls lightly.
>>>>> However, in this case we're talking about an entire *community* of people
>>>>> (high-end computing), not just one or two people. Of course it may still
>>>>> be the case that that community is not important enough to justify the
>>>>> addition of system calls; that's obviously not my call to make!
>>>> I have the feeling that openg stuff is rushed without looking into all
>>>> solutions, that don't require changes to the current interface.
>>> I also get the feeling that interfaces that already do this open-by-handle
>>> stuff haven't been explored either.
>>>
>>> Does anyone here know about the XFS libhandle API? This has been around for
>>> years and it does _exactly_ what these proposed syscalls are supposed to do
>>> (and more).
>>>
>>> See:
>>>
>>> http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=linux&db=man&fname=/usr/share/catman/man3/open_by_handle.3.html&srch=open_by_handle
>>>
>>> For the libhandle man page. Basically:
>>>
>>> openg == path_to_handle sutoc == open_by_handle
>>>
>>> And here for the userspace code:
>>>
>>> http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libhandle/
>>>
>>> Cheers,
>>>
>>> Dave.
>> Thanks for pointing these out Dave. These are indeed along the same lines as
>> the openg()/openfh() approach.
>>
>> One difference is that they appear to perform permission checking on the
>> open_by_handle(), which means that the entire path needs to be encoded in
>> the handle, and makes it difficult to eliminate the path traversal overhead
>> on N open_by_handle() operations.
> 
> open_by_handle() is checking the inode flags for things like
> immutibility and whether the inode is writable to determine if the
> open mode is valid given these flags. It's not actually checking
> permissions. IOWs, open_by_handle() has the same overhead as NFS
> filehandle to inode translation; i.e. no path traversal on open.
> 
> Permission checks are done on the path_to_handle(), so in reality
> only root or CAP_SYS_ADMIN users can currently use the
> open_by_handle interface because of this lack of checking. Given
> that our current users of this interface need root permissions to do
> other things (data migration), this has never been an issue.
> 
> This is an implementation detail - it is possible that file handle,
> being opaque, could encode a UID/GID of the user that constructed
> the handle and then allow any process with the same UID/GID to use
> open_by_handle() on that handle. (I think hch has already pointed
> this out.)
> 
> Cheers,
> 
> Dave.

Thanks for the clarification Dave. So I take it that you would be 
interested in this type of functionality then?

Regards,

Rob