Re: New reflink(2) syscall

[Jamie Lokier <jamie@shareable.org>]

Casey Schaufler wrote:
> Now I have a file that can have a thousand inodes, each of
> which might have a different set of access control characteristics.

>From a security perspective, how is this different from a
thousand separate files?

The copy-on-write is just an optimisation, a filesystem implementation
detail, from a certain perspective.

> With a single inode there is a definitive
> name for the file system object (device/inode) where with multiple
> inodes there is not. 

That's because there isn't a single object to name.  Why do you want
to pretend they are the same object?

They are separate files which share some disk blocks to save space and
time that's all.  A low-level implementation detail.  Completely
separate files can share blocks like that too on some filesystems.

In what way do the shared data blocks between otherwise separate files
have any security implication?

(Ok, ok, timing, ENOSPC, covert communications, but independent files
can trigger such interactions too.)

There's the actual creation of reflinks being invisible to i_nlink
watchers yet not requiring read permission, which is new.  But that
has nothing to do with the shared data: it would have the same
security implication even if reflink was just an ordinary file copy
with its proposed permission check!  :-)

-- Jamie