linux-ext4 - Re: [PATCH v4 00/23] Ext4 Encoding and Case-insensitive support

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] [day] [month] [year] [list]

Date:   Sat, 8 Dec 2018 17:46:19 -0700
From:   Andreas Dilger <adilger@...ger.ca>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Theodore Ts'o <tytso@....edu>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        kernel@...labora.com, linux-ext4@...r.kernel.org,
        krisman@...labora.com
Subject: Re: [PATCH v4 00/23] Ext4 Encoding and Case-insensitive support

On Dec 8, 2018, at 3:59 PM, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> 
> On Sat, Dec 8, 2018 at 1:58 PM Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
>> 
>> I'm hoping you are at least doing it per-directory. That makes at
>> least the "oh, the whole filesystem needs to do this wrong" issue a
>> bit less bad.
> 
> So for example, if you do it per-directory, the rules could be something like:
> 
> - new directories (ie "mkdir()") inherit the icase/folding semantics
> of the parent directory
> 
> - empty directories can have their case/folding rules changed with
> some well-defined interface
> 
> and even from just those simple rules, now some icase behavior could
> be useful to testing.
> 
> Not just filesystem testing (although that would be a thing - thing
> fsstress), but for doing app development in a test directory.
> 
> Apps like git (and GNU fileutils) could use it for having test suites
> for FAT etc filesystems.
> 
> And cross-platform apps could use it as a "I want to check that I do
> the right thing" if you do development on Linux, but might have a
> portable app for other platforms.
> 
> If the whole filesystem is that way, nobody is going to do it. Sure,
> they could do it on a FAT filesystem using a USB disk, but nobody
> really does that. But if you can troivially just run your tests in a
> test subdirectory, it's another thing entirely.
> 
> So this is the kind of thing I mean when I think icase behavior for a
> major Linux filesystem should have a real _design_. It's really quite
> fundamentally different from the "oh, I need FAT to be icase" hack
> that we have now.
> 
> (We might also be able to make the dcache better at handling
> well-defined icase/folding rules, as opposed to the current "just give
> up, let the filesystem hash it" behavior).

In theory, we could store the encoding on a per-entry basis if we
wanted, using the dir_data feature (this would consume 2-3 bytes per
entry, depending on how rich an encoding type we wanted).  The tricky
part is how does the kernel know what the filename encoding is?  How
do we communicate the encoding type back to userspace?

Cheers, Andreas






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