From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joel Becker Subject: Re: New reflink(2) syscall Date: Mon, 4 May 2009 10:49:58 -0700 Message-ID: <20090504174957.GD31249@mail.oracle.com> References: <1241443016.3023.51.camel@localhost.localdomain> <1241456379.3023.173.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: James Morris , lsm , linux-fsdevel@vger.kernel.org To: Stephen Smalley Return-path: Received: from rcsinet11.oracle.com ([148.87.113.123]:61942 "EHLO rgminet11.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751268AbZEDRuo (ORCPT ); Mon, 4 May 2009 13:50:44 -0400 Content-Disposition: inline In-Reply-To: <1241456379.3023.173.camel@localhost.localdomain> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, May 04, 2009 at 12:59:39PM -0400, Stephen Smalley wrote: > On Tue, 2009-05-05 at 01:35 +1000, James Morris wrote: > > What's fundamentally different, though, that the process would only be > > able to then modify the data in a subsequent syscall? > > Since the data doesn't flow through the process at all, it can neither > be leaked nor modified by the process. Whereas normally the data would > be copied into the memory of the process (and potentially leaked > elsewhere) and the process could write any arbitrary data it liked to > the new file. As a result, one might be willing to allow reflink(2) in > situations where one would not be willing to allow a userspace file > copy. Oh, that's a good point. A process using reflink(2) to make a snapshot can do the snap but not modify. That's neat. Joel -- Life's Little Instruction Book #237 "Seek out the good in people." Joel Becker Principal Software Developer Oracle E-mail: joel.becker@oracle.com Phone: (650) 506-8127