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 -- 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
