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 -- 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
