Re: New reflink(2) syscall

[Casey Schaufler <casey@schaufler-ca.com>]

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.