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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
