Re: Testing if two open descriptors refer to the same inode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux