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: Thu, 25 Feb 2010 13:05:17 -0600 Message-ID: <20100225190517.GA23221@us.ibm.com> References: <1266558149-11460-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jonathan Corbet , hch@infradead.org, viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org To: "Aneesh Kumar K. V" Return-path: Received: from e32.co.us.ibm.com ([32.97.110.150]:49705 "EHLO e32.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759430Ab0BYTFp (ORCPT ); Thu, 25 Feb 2010 14:05:45 -0500 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e32.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id o1PIxK8Z017448 for ; Thu, 25 Feb 2010 11:59:20 -0700 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o1PJ5K1c117902 for ; Thu, 25 Feb 2010 12:05:21 -0700 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o1PJ7dCQ003982 for ; Thu, 25 Feb 2010 12:07:40 -0700 Content-Disposition: inline In-Reply-To: <87wry15g8x.fsf@linux.vnet.ibm.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Quoting Aneesh Kumar K. V (aneesh.kumar@linux.vnet.ibm.com): > On Thu, 25 Feb 2010 12:11:13 -0600, "Serge E. Hallyn" wrote: > > Quoting Aneesh Kumar K. V (aneesh.kumar@linux.vnet.ibm.com): > > > On Thu, 25 Feb 2010 09:19:09 -0600, "Serge E. Hallyn" wrote: > > > > Quoting Jonathan Corbet (corbet@lwn.net): > > > > > On Wed, 24 Feb 2010 22:53:23 -0600 > > > > > "Serge E. Hallyn" 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/)? 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