linux-ext4 - Re: [RFC] Ext4 case insensitive proposal

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]

Message-ID: <874lr4q3cw.fsf@dilma.collabora.co.uk>
Date:   Thu, 12 Oct 2017 03:36:47 -0300
From:   Gabriel Krisman Bertazi <krisman@...labora.co.uk>
To:     Theodore Ts'o <tytso@....edu>
Cc:     adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org
Subject: Re: [RFC] Ext4 case insensitive proposal

Theodore Ts'o <tytso@....edu> writes:

Hi Ted,

> This isn't a complete implementation of my proposal.  In particular
> one of the things which is missing is:
>
>    1.  If case-insensitivity is enabled, override the default dcache hash
>    and compare operations to ones that are case insensitive in ext4's
>    dcache_operations structure.
>
> This is needed so there is a single dcache entry for case-folded file
> names.

Sorry for the delay in replying.  In fact, the dcache hash operations
were part of my original patch, but I dropped it before submitting in
favor of d_add_ci(), which I expected would prevent duplication of the
same elements, differing only by case in the dentry cache.

I have shared it in a different branch if you want to take a look.

git://git.collabora.com/git/user/krisman/linux.git -b ext4-insensitive-dcache-patch

Despite that, I've been learning my way in the VFS subsystem,
investigating the suggestion made by you and HCH on the thread I
mentioned:

> I talked to Christoph at the Plumbers Closing party, and he suggested
> that we get something simple in first which (a) assumes no on-disk
> format changes, (b) does everything in the VFS layer, by using a
> MS_CASE_FOLD, uses a case-insensitive dentry hash, and which degrades
> to a brute force search in the VFS by using readdir interfaces if the
> direct lookup does not succeed, and (c) at least initially assumes
> only ASCII.

My current question on this approach is how the MS_CASE_FOLD could be
exposed to userspace.  It is not any system call that can receive a new
flag to request an insensitive lookup.  In this case, are you
considering a new set of system calls to perform case-insensitive
lookups, some per-process thing or another approach I'm not considering?
Can you provide me with more information on this?

Thanks for helping out on reviewing my code.

--
Gabriel Krisman Bertazi