Thread (78 messages) 78 messages, 14 authors, 2024-10-21

Re: [RFC PATCH v1 1/7] fs: Add inode_get_ino() and implement get_ino() for NFS

From: Christoph Hellwig <hch@infradead.org>
Date: 2024-10-14 09:02:18
Also in: linux-fsdevel, linux-nfs

On Mon, Oct 14, 2024 at 07:40:37PM +1100, Burn Alting wrote:
As someone who lives in the analytical user space of Linux audit,  I take it
that for large (say >200TB) file systems, the inode value reported in audit
PATH records is no longer forensically defensible and it's use as a
correlation item is of questionable value now?
What do you mean with forensically defensible?

A 64-bit inode number is supposed to be unique.  Some file systems
(most notably btrfs, but probably also various non-native file system)
break and this, and get away with lots of userspace hacks papering
over it.  If you are on a 32-bit system and not using the LFS APIs
stat will fail with -EOVERFLOW.  Some file systems have options to
never generate > 32bit inode numbers.  None of that is directly
related to file system size, although at least for XFS file system
size is one relevant variable, but 200TB is in no way relevant.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help