From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Aneesh Kumar K. V" Subject: Re: [RFC PATCH] Generic name to handle and open by handle syscalls Date: Thu, 25 Feb 2010 23:25:34 +0530 Message-ID: <87y6ih5hex.fsf@linux.vnet.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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: hch@infradead.org, viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org To: "Serge E. Hallyn" , Jonathan Corbet Return-path: Received: from e23smtp02.au.ibm.com ([202.81.31.144]:56602 "EHLO e23smtp02.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933183Ab0BYRzw (ORCPT ); Thu, 25 Feb 2010 12:55:52 -0500 Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [202.81.31.247]) by e23smtp02.au.ibm.com (8.14.3/8.13.1) with ESMTP id o1PHqfGm024260 for ; Fri, 26 Feb 2010 04:52:41 +1100 Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o1PHoK4A950450 for ; Fri, 26 Feb 2010 04:50:20 +1100 Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o1PHtnob017440 for ; Fri, 26 Feb 2010 04:55:50 +1100 In-Reply-To: <20100225151909.GA7966@us.ibm.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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 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