From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Smalley Subject: Re: [RFC] The reflink(2) system call v4. Date: Fri, 15 May 2009 07:54:27 -0400 Message-ID: <1242388467.29973.11.camel@localhost.localdomain> References: <20090507221535.GA31624@mail.oracle.com> <4A039FF8.7090807@hp.com> <20090508031018.GB8611@mail.oracle.com> <20090511204011.GB30293@mail.oracle.com> <20090511223414.GA28209@mail.oracle.com> <1242130714.31807.25.camel@localhost.localdomain> <20090512172200.GC6896@mail.oracle.com> <1242149567.31807.90.camel@localhost.localdomain> <20090512180339.GG6896@mail.oracle.com> <1242151493.31807.94.camel@localhost.localdomain> <1242324387.21772.92.camel@localhost.localdomain> <1242325533.21772.102.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Joel Becker , jim owens , ocfs2-devel@oss.oracle.com, viro@zeniv.linux.org.uk, mtk.manpages@gmail.com, linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org To: James Morris Return-path: Received: from msux-gh1-uea02.nsa.gov ([63.239.67.2]:47935 "EHLO msux-gh1-uea02.nsa.gov" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750717AbZEOMBn (ORCPT ); Fri, 15 May 2009 08:01:43 -0400 In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, 2009-05-15 at 09:25 +1000, James Morris wrote: > On Thu, 14 May 2009, Stephen Smalley wrote: > > > And you can likely make preserve_security a simple bool (set from some > > caller-provided flag) rather than an int. At which point the SELinux > > wiring for the new hook would be something like this: > > > > If we are preserving security attributes on the reflink, then treat it > > like creating a link to an existing file; > > Do we also need to somewhat consider it like a new file? e.g. in the case > of create_sid being set (if different to the existing security attribute), > I believe we need to fail the operation because security attributes are > not preserved, and also decide which error code to return (the user may be > confused if it's EACCES -- EINVAL might be better). Similar for reflinks > on a context mounted file system, although create_sid needs to be checked > during inode instantiation (unless we, say, add set a preserve_sid flag > which overrides create_sid and is cleared upon use). The create_sid is not relevant in the preserve_security==1 case; the filesystem will always preserve the security context from the original inode on the new inode in that case. The create_sid won't ever be used in that case, as it only gets applied if the filesystem calls security_inode_init_security() to obtain the attribute (name, value) pair for a new inode, and the filesystem will only do that in the preserve_security==0 case. -- Stephen Smalley National Security Agency