From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joel Becker Subject: Re: New reflink(2) syscall Date: Tue, 5 May 2009 09:46:10 -0700 Message-ID: <20090505164610.GA7835@mail.oracle.com> References: <1241443016.3023.51.camel@localhost.localdomain> <20090504163514.GB31249@mail.oracle.com> <1241458669.3023.203.camel@localhost.localdomain> <20090504180855.GE31249@mail.oracle.com> <1241465446.3023.228.camel@localhost.localdomain> <20090504210356.GA25313@mail.oracle.com> <20090504213032.GE25313@mail.oracle.com> <1241523841.3023.244.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: Content-Disposition: inline In-Reply-To: <1241523841.3023.244.camel@localhost.localdomain> Sender: linux-security-module-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Tue, May 05, 2009 at 07:44:01AM -0400, Stephen Smalley wrote: > On Mon, 2009-05-04 at 14:30 -0700, Joel Becker wrote: > > Wouldn't testing inode_change_ok() be the right thing here? > > Hits up uid, gid, perms, times. > > I don't think so, as you aren't actually changing the attributes of an > inode but rather are cloning the attributes from the original to the new > one. And I doubt you want the same level of restrictiveness, since in > the reflink(2) case, the process is limited to only preserving the > original attributes (not setting arbitrary values) and only on the same > content/data (not on arbitrary content/data). Ok, I was looking at avoiding re-implementing the UID/GID checks, but I suppose I'll just do them straight up in vfs_reflink(). Joel -- Life's Little Instruction Book #407 "Every once in a while, take the scenic route." Joel Becker Principal Software Developer Oracle E-mail: joel.becker@oracle.com Phone: (650) 506-8127