linux-ext4 - Re: Inquiry: Possible built-in support for longer filenames in ext4 (beyond 256 bytes)

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: <20251210232459.GD42106@macsyma.local>
Date: Thu, 11 Dec 2025 08:24:59 +0900
From: "Theodore Tso" <tytso@....edu>
To: Winston Wen <wentao@...ontech.com>
Cc: linux-ext4@...r.kernel.org
Subject: Re: Inquiry: Possible built-in support for longer filenames in ext4
 (beyond 256 bytes)

On Wed, Dec 10, 2025 at 05:32:02PM +0800, Winston Wen wrote:
> To better understand, I’ve reviewed the readdir/getdents man pages and
> the glibc struct dirent definition. It appears that d_name is
> implemented as a flexible array member rather than a fixed-size array
> of 256 bytes.

Intresting; the struture definition I quoted was from the readdir man
page.

I suspect there may be some number of random failures that might occur
because of hidden dependencies on the historical / traditional value
of NAME_MAX.  For example, it might be OK for glibc; but what about
other C libraries that ship on Linux, such as musl, dietlibc, bionic,
etc.?

> Going back to our original question: we were curious whether it might
> be possible to support longer filenames natively within ext4 itself
> (rather than through FUSE), perhaps via on-disk format extension or
> auxiliary storage like xattrs. If this is architecturally feasible, we
> would be very interested in exploring it further.

Well, extended attributes won't work, because xattrs are associated
with the inode, not the directory entry.  So you need to handle cases
where the file has multiple hard links.  And if you are doing a lookup
by long file name, there's a chicken and egg problem; you can't match
against the full filename until you read the xattr, and you can't do
that until you've lookup.

The only way to do this would be to make an incompatible change to the
directory layout.  And doing this would require either refactoring and
doing extensive rework of the code in fs/ext4/namei.c and
fs/ext4/dir.c, to support both the the original v1 version of the
directory layout, and the v2 version of the directory layout, as well
as handling the v2 verison of the directory when it is encrypted.
It's _doable_, but it's a huge amount of work.  So the question is
whether it's worth it.  If this is some random class project where you
don't care about bugs or reliability, that's one thing.  If this is
something that need to be hardened for production usage, it's quite a
lot more work.

Why are you interested in doing this?  Is there business justification
such that your company would be willing invest a significant amount of
effort?

Cheers,

						- Ted