On 14/10/24 20:02, Christoph Hellwig wrote:
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?
If the auditd system only maintains a 32 bit variable for an inode
value, when it emits an inode number, then how does one categorically
state/defend that the inode value in the audit event is the actual one
on the file system. The PATH record will offer one value (32 bits) but
the returned inode value from a stat will return another (the actual 64
bit value). Basically auditd would not be recording the correct value.
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.
My reference to the filesystem size was a quick and dirty estimate of
when one may see more than 2^32 inodes on a single filesystem. What I
failed to state (my apologies) is that this presumed an xfs filesystem
with default values when creating the file system. (A quick check on an
single 240TB xfs filesystem advised more than 5000000000 inodes were
available).
