Re: New reflink(2) syscall

[Jamie Lokier <jamie@shareable.org>]

Casey Schaufler wrote:
> > Even though you can't read the file if you couldn't read it before,
> > you now have a link to it which might preserve data they don't want to
> > be preserved.
> >
> > So reflink() should, perhaps, be more restricted than link().
>
> If I use reflink() I end up with two sets of initially identical
> security credentials, which is the right thing, but now read access
> (I'll skip write access for now) can be set differently on the two
> inodes via chmod(), chgrp(), chown(), chacl(), and setxattr(). Or
> have I missed something? Is this really your intent?

I guess the idea is that if you can do
chmod/chgrp/chown/chacl/setxattr on the new inode, then you had
sufficient permission to do it on the old inode anyway, so you can
read the data either way.

My points are: (1) You can do it covertly with reflink() - the owner
doesn't know - whereas with link() or just accessing the file
directly, they will notice.  (2) You can grab a reflink now while you
don't have permission to read the file, just inadvertant access to
it's directory entry, and perhaps some time in the future you will
have access to read the snapshot you have just grabbed.

(2) Cannot happen without reflink, because the source file owner may
know they have deleted or wiped the file before you are granted enough
permissions to be able to read it.  Heck, the owner might be the
system administrator, carefully scrubbing their penguin porn
collection just before they promote you to be another administrator.
reflink() lets you see what they had tantalisingly kept unreadable but
ls'able before - if you had the foresight to use it.

-- Jamie