From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Smalley Subject: Re: New reflink(2) syscall Date: Tue, 05 May 2009 14:41:22 -0400 Message-ID: <1241548882.3023.356.camel@localhost.localdomain> References: <1241443016.3023.51.camel@localhost.localdomain> <1241456379.3023.173.camel@localhost.localdomain> <20090505180024.GI7835@mail.oracle.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: James Morris , lsm , linux-fsdevel@vger.kernel.org To: Joel Becker Return-path: In-Reply-To: <20090505180024.GI7835@mail.oracle.com> Sender: linux-security-module-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Tue, 2009-05-05 at 11:00 -0700, Joel Becker wrote: > 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: > > > Agreed, perhaps something like: > > > > > > int security_inode_reflink(struct dentry *dentry, struct inode *dir); > > > > I'd pass the same arguments as vfs_reflink(), i.e. old_dentry, dir, > > new_dentry. > > I'm about to insert this bit. I agree with > security_inode_reflink(old_dentry, dir, new_dentry), but I note that > security_path_reflink() was proposed in another email, and I'm guessing > I should add both? The TOMOYO folks said that calling security_path_link() would suffice for their purposes. SELinux would want security_inode_reflink() from vfs_reflink(). -- Stephen Smalley National Security Agency