From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Smalley Subject: Re: New reflink(2) syscall Date: Tue, 05 May 2009 13:44:11 -0400 Message-ID: <1241545451.3023.341.camel@localhost.localdomain> 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> <20090504231334.GA17486@mit.edu> <20090505164700.GB7835@mail.oracle.com> <1241542618.7244.76.camel@think.oraclecorp.com> <20090505171331.GG7835@mail.oracle.com> <20090505173423.GH17486@mit.edu> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Chris Mason , James Morris , lsm , linux-fsdevel@vger.kernel.org To: Theodore Tso Return-path: In-Reply-To: <20090505173423.GH17486@mit.edu> Sender: linux-security-module-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Tue, 2009-05-05 at 13:34 -0400, Theodore Tso wrote: > On Tue, May 05, 2009 at 10:13:31AM -0700, Joel Becker wrote: > > On Tue, May 05, 2009 at 12:56:58PM -0400, Chris Mason wrote: > > > On Tue, 2009-05-05 at 09:47 -0700, Joel Becker wrote: > > > > Because then you have to change the entire security structure, > > > > and you aren't a snapshot anymore. > > > > > > I won't argue with the security part, but the snapshot part could just > > > as easily be defined by the data and not the inode. > > > > In ZFS/btrfs/WAFL/disk array snaps, if you go back to a snap > > does the selinux context or acls or equivalent appear different? I don't > > think so, and I expect people would be really upset if they had to know > > all the restorecon/acl-fu to get it right. > > OK, now I understand; sorry, I didn't realize that when you said > "snapshot", what you were really talking about was a way to implement > WAFL-style snapshots, where reflink was a low-level operation that > would be used to implement that particular use case. Hmm, maybe the > answer is that we implement reflinkat(2) with flags that indicate > whether this is supposed to be more like a hard link (i.e., acl and > ownership should be preserved) or more a like a copy (i.e., acl is > inherited from the new containing directory's directory creation acl, > uid/guid are set using the standard rules for creating new inodes). > > Both use cases are equally valid, and I imagine there would be > interest in using reflinks both for snapshots and as a very > lightweight copy operation by commands like /bin/cp. Not arguing against this, but just to note: the security model will differ depending on these flags, as the link-like case doesn't require the caller to have read access to the file (the data is no more accessible than it was before), whereas the copy-like case requires the caller to have read access to the original file since the data "leaks" into a container with potentially different access constraints. -- Stephen Smalley National Security Agency