linux-kernel - Re: [PATCH 0/6] overlayfs + casefolding

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: <7sa3ouxmocenlbh3r3asraedbbr6svljroyml3dpcoerhamwmy@gb32bhm4jqvh>
Date: Tue, 20 May 2025 10:44:31 -0400
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Amir Goldstein <amir73il@...il.com>
Cc: linux-fsdevel@...r.kernel.org, linux-bcachefs@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-unionfs@...r.kernel.org, 
	Miklos Szeredi <miklos@...redi.hu>, Alexander Viro <viro@...iv.linux.org.uk>, 
	Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>
Subject: Re: [PATCH 0/6] overlayfs + casefolding

On Tue, May 20, 2025 at 04:33:14PM +0200, Amir Goldstein wrote:
> On Tue, May 20, 2025 at 4:12 PM Kent Overstreet
> > Amir, you've got two widely used filesystem features that conflict and
> > can't be used on the same filesystem.
> >
> > That's _broken_.
> 
> Correct.
> 
> I am saying that IMO a smaller impact (and less user friendly) fix is more
> appropriate way to deal with this problem.

Less user friendly is an understatement.

Obscure errors that only get reported via overloaded standard error
codes is a massive problem today, for _developers_ - have you never had
a day of swearing over trying to track down where in a massive subsystem
an -EINVAL is coming from?

It's even worse for end users that don't know to check the dmesg log.

And I support my code, so these would turn into bug reports coming
across my desk - no thanks; I already get enough weird shit from other
subsystems that I have to look at and at least triage.

> > Users hate partitioning just for separate /boot and /home, having to
> > partition for different applications is horrible. And since overlay fs
> > is used under the hood by docker, and casefolding is used under the hood
> > for running Windows applications, this isn't something people can
> > predict in advance.
> 
> Right, I am not expecting users to partition by application,
> but my question was this:
> 
> When is overlayfs created over a subtree that is only partially case-folded?
> 
> Obviously, docker would create overlayfs on parts of the fs
> and smbd/cygwin could create a case folder subtree on another
> part of the fs.
> I just don't see a common use case when these sections overlap.

Today, you cannot user docker and casefolding on _different parts of_
the same filesystem.

So yees, today users do have to partition by application, or only use
one feature or the other.

This isn't about allowing casefolding and overlayfs to fix on the same
subtree, that would be a bigger project.

> Perhaps I am wrong (please present real world use cases),
> but my claim is that this case is not common enough and therefore,
> a suboptimal EIO error from lookup is good enough to prevert crossing
> over into the case folded zone by mistake, just as EIO on lookup is
> enough to deal with the unsupported use case of modifying
> overlayfs underlying layers with overlay is mounted.
> 
> BTW, it is not enough to claim that there is no case folding for the
> entire subtree to allow the mount.
> For overlayfs to allow d_hash()/d_compare() fs must claim that
> these implementations are the default implementation in all subtree
> or at least that all layers share the same implementation.

I honestly don't know what you're claiming here.