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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240729133601.GA557749@mit.edu>
Date: Mon, 29 Jul 2024 09:36:01 -0400
From: "Theodore Ts'o" <tytso@....edu>
To: Mateusz Guzik <mjguzik@...il.com>
Cc: Florian Weimer <fweimer@...hat.com>, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
        Dave Chinner <dchinner@...hat.com>
Subject: Re: Testing if two open descriptors refer to the same inode

On Mon, Jul 29, 2024 at 12:18:15PM +0200, Mateusz Guzik wrote:
> 
> Are you claiming on-disk inode numbers are not guaranteed unique per
> filesystem? It sounds like utter breakage, with capital 'f'.

The reality is that there exists file systems which do not return
unique inode numbers.  For example, there are virtiofs implementations
which pass the inode numbers straight through with a fixed dev_t.  If
you have a large number of packages mounted via iscsi, and those
packages include shared libraries, then you can have two different
shared libraries with the same inode number, and then you can watch
the dynamic liunker get Very Confused, and debugging the problem can
be.... interesting.  (Three gueses how I found out about this, and the
first two don't count.  Yes, we figured out a workaround.)

So that breakage exists already, today.

For people who don't like this, they can stick to those file systems
that still guarantee unique inode numbers, at least for local disk
file systems --- for example, to use ext4 and xfs, over btrfs and
bcachefs.

However, this is a short-term expedient, and in the long term, we will
need to guide userspace to use something that is more likely to work,
such as file handles.  And ideally, this needs to be standardized at
venues such as the Austin Group, so that it becomes interfaces which
are used across operating systems, not just for Linux.  It's going to
be a multi-year, if not decade-long, effort...

						- Ted