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 09:19:09 -0600 Message-ID: <20100225151909.GA7966@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Aneesh Kumar K. V" , hch@infradead.org, viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org To: Jonathan Corbet Return-path: Received: from e33.co.us.ibm.com ([32.97.110.151]:55688 "EHLO e33.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759301Ab0BYPTb (ORCPT ); Thu, 25 Feb 2010 10:19:31 -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 o1PFFxJa026774 for ; Thu, 25 Feb 2010 08:15:59 -0700 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id o1PFJE2W220030 for ; Thu, 25 Feb 2010 08:19:24 -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 o1PFLVxs019306 for ; Thu, 25 Feb 2010 08:21:31 -0700 Content-Disposition: inline In-Reply-To: <20100225073002.1f6ef3cd@bike.lwn.net> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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... -serge