On Mon, Jul 29, 2024 at 12:18:15PM GMT, Mateusz Guzik wrote: > On Mon, Jul 29, 2024 at 08:55:46AM +0200, Florian Weimer wrote: > > It was pointed out to me that inode numbers on Linux are no longer > > expected to be unique per file system, even for local file systems. > > I don't know if I'm parsing this correctly. > > Are you claiming on-disk inode numbers are not guaranteed unique per > filesystem? It sounds like utter breakage, with capital 'f'. > > I know the 32-bit inode allocation code can result in unintentional > duplicates after wrap around (see get_next_ino), but that's for > in-memory stuff only(?) like pipes, so perhaps tolerable. > > Anyhow, the kernel recently got F_DUPFD_QUERY which tests if the *file* > object is the same. > > While the above is not what's needed here, I guess it sets a precedent > for F_DUPINODE_QUERY (or whatever other name) to be added to handily > compare inode pointers. It may be worthwhile regardless of the above. > (or maybe kcmp could be extended?) We don't use kcmp() for such core operations. It's overkill and security sensitive so quite a few configs don't enable it. See [1] for details how kcmp() can be used to facilitate UAF attacks and defeat probabilistic UAF mitigations by using ordering information. So that ordering requirement should really go out the window. Another thing is that kcmp() works cross-process which is also out of scope for this. kcmp() really should be reserved for stuff that checkpoint/restore in userspace needs and that's otherwise too fruity to be implemented in our regular apis. [1]: https://googleprojectzero.blogspot.com/2021/10/how-simple-linux-kernel-memory.html
