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(). > 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? -- 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
