Theodore Tso wrote: > 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. > > On the topic of security modeling, I'd like to point out that one of the reasons that Linux has been such a hit with the security community is that you can model the file system accesses easily because no matter what you do you end up at a definitive access control point, the inode. Now I have a file that can have a thousand inodes, each of which might have a different set of access control characteristics. All existing Linux security descriptions go strait out the window. Once a chown() has occurred any chance of limiting the propagation of access rights is lost. With a single inode there is a definitive name for the file system object (device/inode) where with multiple inodes there is not. I'm not ignoring the copy-on-write, for a file that has not been changed since the reflink() call that doesn't matter. -- 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
