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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
