linux-kernel - Re: [RFC PATCH 2/4] mm: shmem: Support case-insensitive file name lookups

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: <7826ef62-49a0-d140-2920-5bdab5bda58a@collabora.com>
Date:   Wed, 24 Mar 2021 17:44:25 -0300
From:   André Almeida <andrealmeid@...labora.com>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     Hugh Dickins <hughd@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        krisman@...labora.com, smcv@...labora.com, kernel@...labora.com,
        linux-mm@...ck.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, Daniel Rosenberg <drosen@...gle.com>
Subject: Re: [RFC PATCH 2/4] mm: shmem: Support case-insensitive file name
 lookups

Hi Al Viro,

Às 20:19 de 23/03/21, Al Viro escreveu:
> On Tue, Mar 23, 2021 at 04:59:39PM -0300, André Almeida wrote:
> 
>> * dcache handling:
>>
>> For now, negative lookups are not inserted in the dcache, since they
>> would need to be invalidated anyway, because we can't trust missing file
>> dentries. This is bad for performance but requires some leveraging of
>> the VFS layer to fix. We can live without that for now, and so does
>> everyone else.
> 
> "For now"?  Not a single practical suggestion has ever materialized.
> Pardon me, but by now I'm very sceptical about the odds of that
> ever changing.  And no, I don't have any suggestions either.

Right, I'll reword this to reflect that there's no expectation that this 
will be done, while keeping documented this performance issue.

> 
>> The lookup() path at tmpfs creates negatives dentries, that are later
>> instantiated if the file is created. In that way, all files in tmpfs
>> have a dentry given that the filesystem exists exclusively in memory.
>> As explained above, we don't have negative dentries for casefold files,
>> so dentries are created at lookup() iff files aren't casefolded. Else,
>> the dentry is created just before being instantiated at create path.
>> At the remove path, dentries are invalidated for casefolded files.
> 
> Umm...  What happens to those assertions if previously sane directory
> gets case-buggered?  You've got an ioctl for doing just that...
> Incidentally, that ioctl is obviously racy - result of that simple_empty()
> might have nothing to do with reality before it is returned to caller.
> And while we are at it, simple_empty() doesn't check a damn thing about
> negative dentries in there...
> 

Thanks for pointing those issues. I'll move my lock at IOCTL to make 
impossible to change directory attributes and add a file there at the 
same time. About the negative dentries that existed before at that 
directory, I believe the way to solve this is by invalidating them all. 
How that sound to you?

Thanks,
	André