On Tue, May 05, 2009 at 10:38:51PM -0700, Casey Schaufler wrote: > It's different from 1000 separate files because I can now have > one set of data blocks with read access controlled by 1000 different > users. > > # chown user000 rfile000 > ... > # chown user999 rfile999 > > now 1000 different users can grant access to those blocks, > so long as they don't change. Without reflink() I know that if > I own the file, it isn't open (fuser says so) and it is mode 700 > that noone else can read it sans privilege. With reflink() not > only is this not true, but I can't find out who might be able to > read it. Changing the permissions, ACL, SELinux label, Smack label, > or TOMOYO policy won't help, because there may be another inode > out there somewhere that I can't even access that is granting the > rest of the world access. Sure, but if the file is readable by 1000 different users, then they they could each make 1000 different copies of the file. So the "reflink-copy-optimization" variant (i.e., do a reflink where the initial owner is the user doing the reflink, and where the initial ACL is the destination directory's default creation ACL, and the initial group ownership, etc. is exactly the same as if you had created a new file in the destination directory).... then this acts *precisely* the same as an optimized file copy. So if you allow someone to do a "reflink-copy" only when they would be allowed to read the file, it's merely a low-level optimization. In contrast, the "reflink-link" variant which OCFS2 has prototyped acts more like a link --- except it gets a new inode number. From a security perspective, you treat this exactly as if it were a link. In both cases, you treat the quota as if the new file was created, since the original file could be removed at any time, or the COW link could be snapped and the file really copied. > Yeah, I can see the argument, I'm just not sure that I could > turn around and sell it to an eager-puppy security evaluator > fresh out of a PHD program at the U of Maryland. That's going to be true of *any* new filesystem feature, wouldn't it? I don't think that's a justifiable reason not to implement a new feature. In any case, if the security evaluators are that silly, you can always simply remove the ability to use reflinks altogether. That might break some application programs, but if the some that breaks some General or Admiral's pet project, I'm sure pressure can be brought to bear on the security evaluator. :-) - 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
