From mboxrd@z Thu Jan  1 00:00:00 1970
From: Matthew Wilcox <matthew@wil.cx>
Subject: Re: openg and path_to_handle
Date: Wed, 6 Dec 2006 13:50:24 -0700
Message-ID: <20061206205023.GD3013@parisc-linux.org>
References: <20061129090450.GA16296@infradead.org> <20061129122313.GG14315@parisc-linux.org> <20061129123913.GA15994@infradead.org> <4570ACD1.7060800@mcs.anl.gov> <f158dc670612011835u2bbd39d2sbe8abf2a9d6b9e23@mail.gmail.com> <4574BF52.6090600@mcs.anl.gov> <f158dc670612050847y197c232bp6f967934c5769bf3@mail.gmail.com> <20061206094805.GB33919298@melbourne.sgi.com> <4576E783.7020402@mcs.anl.gov> <20061206204005.GC33919298@melbourne.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Rob Ross <rross@mcs.anl.gov>, Latchesar Ionkov <lionkov@lanl.gov>,
	Christoph Hellwig <hch@infradead.org>,
	Gary Grider <ggrider@lanl.gov>, linux-fsdevel@vger.kernel.org
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from palinux.external.hp.com ([192.25.206.14]:34061 "EHLO
	mail.parisc-linux.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S937629AbWLFUuZ (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Wed, 6 Dec 2006 15:50:25 -0500
To: David Chinner <dgc@sgi.com>
Content-Disposition: inline
In-Reply-To: <20061206204005.GC33919298@melbourne.sgi.com>
Sender: linux-fsdevel-owner@vger.kernel.org
List-Id: linux-fsdevel.vger.kernel.org

On Thu, Dec 07, 2006 at 07:40:05AM +1100, David Chinner wrote:
> 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.)

While it could do that, I'd be interested to see how you'd construct
the handle such that it's immune to a malicious user tampering with it,
or saving it across a reboot, or constructing one from scratch.

I suspect any real answer to this would have to involve cryptographical
techniques (say, creating a secure hash of the information plus a
boot-time generated nonce).  Now you're starting to use a lot of bits,
and compute time, and you'll need to be sure to keep the nonce secret.