Re: New reflink(2) syscall

[Stephen Smalley <sds@tycho.nsa.gov>]

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