Casey Schaufler wrote: > Now I have a file that can have a thousand inodes, each of > which might have a different set of access control characteristics. >From a security perspective, how is this different from a thousand separate files? The copy-on-write is just an optimisation, a filesystem implementation detail, from a certain perspective. > With a single inode there is a definitive > name for the file system object (device/inode) where with multiple > inodes there is not. That's because there isn't a single object to name. Why do you want to pretend they are the same object? They are separate files which share some disk blocks to save space and time that's all. A low-level implementation detail. Completely separate files can share blocks like that too on some filesystems. In what way do the shared data blocks between otherwise separate files have any security implication? (Ok, ok, timing, ENOSPC, covert communications, but independent files can trigger such interactions too.) There's the actual creation of reflinks being invisible to i_nlink watchers yet not requiring read permission, which is new. But that has nothing to do with the shared data: it would have the same security implication even if reflink was just an ordinary file copy with its proposed permission check! :-) -- 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
