From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Serge E. Hallyn" Subject: Re: [RFC PATCH] Generic name to handle and open by handle syscalls Date: Fri, 26 Feb 2010 13:56:53 -0600 Message-ID: <20100226195653.GA24861@us.ibm.com> References: <20100222160659.48a91f82@bike.lwn.net> <87ocjgib0j.fsf@linux.vnet.ibm.com> <20100225045323.GA25549@us.ibm.com> <20100225073002.1f6ef3cd@bike.lwn.net> <20100225151909.GA7966@us.ibm.com> <87y6ih5hex.fsf@linux.vnet.ibm.com> <20100225181113.GB16522@us.ibm.com> <87wry15g8x.fsf@linux.vnet.ibm.com> <20100225190517.GA23221@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Aneesh Kumar K. V" , Jonathan Corbet , hch@infradead.org, viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org To: Andreas Dilger Return-path: Received: from e33.co.us.ibm.com ([32.97.110.151]:35438 "EHLO e33.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965860Ab0BZT5L (ORCPT ); Fri, 26 Feb 2010 14:57:11 -0500 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e33.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id o1QJreFo026265 for ; Fri, 26 Feb 2010 12:53:40 -0700 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id o1QJuu7V125756 for ; Fri, 26 Feb 2010 12:57:06 -0700 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o1QJutNW026780 for ; Fri, 26 Feb 2010 12:56:55 -0700 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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/)? 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