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: <20240729.113049-lax.waffle.foxy.nit-U1v9CY38xge@cyphar.com>
Date: Mon, 29 Jul 2024 21:40:57 +1000
From: Aleksa Sarai <cyphar@...har.com>
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>, 
	Christian Brauner <brauner@...nel.org>
Subject: Re: Testing if two open descriptors refer to the same inode

On 2024-07-29, Mateusz Guzik <mjguzik@...il.com> wrote:
> On Mon, Jul 29, 2024 at 12:57 PM Florian Weimer <fweimer@...hat.com> wrote:
> > > On Mon, Jul 29, 2024 at 12:40:35PM +0200, Florian Weimer 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'.
> > >>
> > >> Yes, POSIX semantics and traditional Linux semantics for POSIX-like
> > >> local file systems are different.
> > >
> > > Can you link me some threads about this?
> >
> > Sorry, it was an internal thread.  It's supposed to be common knowledge
> > among Linux file system developers.  Aleksa referenced LSF/MM
> > discussions.
> 
> So much for open development :-P

To be clear, this wasn't _decided_ at LSF/MM, it was brought up as a
topic. There is an LWN article about the session that mentions the
issue[1].

My understanding is that the btrfs and bcachefs folks independently
determined they cannot provide this guarantee. As far as I understand,
the reason why is that inode number allocation on btree filesystems
stores information about location and some other bits (maybe subvolumes)
in the bits, making it harder to guarantee there will be no collisions.

Don't quote me on that though, I'm sure they'll tell me I'm wrong when
they wake up. :D

As the article mentions, Kent Overstreet suggested trying to see how
many things break if you build a kernel where all inode numbers are the
same (my guess would be "very badly" -- aside from the classic problem
of hardlink detection, a lot of programs key things by (dev, ino), and
some inode numbers are guaranteed by the kernel for pseudo-filesystems
like PROC_ROOT_INO).

[1]: https://lwn.net/Articles/975444/

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)