Re: New reflink(2) syscall

[Theodore Tso <tytso@mit.edu>]

On Tue, May 05, 2009 at 10:56:03AM -0700, Joel Becker wrote:
> On Tue, May 05, 2009 at 01:44:11PM -0400, Stephen Smalley wrote:
> > > 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.
> 
> 	Sure, but you can start with a reflink and then do what you want
> to it.
> 
> > 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.
> 
> 	Yeah, another reason why I don't want to complicate the
> behavior.  I defined it as "the operation is like link(2)" for a reason
> :-)

The security model *is* the problem, however.  If we have a mode where
reflink acts like cp, then it doesn't require anything special in
terms of CAP_FOWNER.  It really is the same as a copy command.   

So sure, you could start with a reflink and then modify it, but if
you're an unprivileged user, you won't be able to create the reflink
in the first place.

					- Ted