Re: New reflink(2) syscall

[Theodore Tso <tytso@mit.edu>]

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