Re: New reflink(2) syscall

[Stephen Smalley <sds@tycho.nsa.gov>]

On Tue, 2009-05-05 at 23:45 +0100, Jamie Lokier wrote:
> Stephen Smalley wrote:
> > 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)
> 
> One security difference between reflink() and link() when linking to
> _other_ user's files is they can tell if you suddenly got a link to
> their file, from their i_nlink.  They can be suspicious and maybe
> overwrite the file in place, truncate it or something, and look around
> for the link you created in a secret place in your /home.
> 
> But they can't see if you got a reflink to their file.
> 
> 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().

That's why I suggested is_ower_or_cap() or a similar test in the case
where reflink(2) is applied to an inode owned by a user other than the
caller's fsuid.

-- 
Stephen Smalley
National Security Agency