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: <874jlz69l2.fsf@suse.de>
Date:   Wed, 19 Jul 2023 14:27:05 -0400
From:   Gabriel Krisman Bertazi <krisman@...e.de>
To:     Eric Biggers <ebiggers@...nel.org>
Cc:     viro@...iv.linux.org.uk, brauner@...nel.org, tytso@....edu,
        jaegeuk@...nel.org, linux-fsdevel@...r.kernel.org,
        linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net
Subject: Re: [PATCH v2 4/7] libfs: Support revalidation of encrypted
 case-insensitive dentries

Eric Biggers <ebiggers@...nel.org> writes:

> Why would order matter?  If either "feature" wants the dentry to be invalidated,
> then the dentry gets invalidated.

For instance, I was wondering makes sense for instance to memcmp d_name for
!DCACHE_NOKEY_NAME or if we wanted fscrypt_d_revalidate to come first.

>> Note we will start creating negative dentries in casefold directories after
>> patch 6/7, so unless we disable it here, we will start calling
>> fscrypt_d_revalidate for negative+casefold.
>
> fscrypt_d_revalidate() only cares about the DCACHE_NOKEY_NAME flag, so that's
> not a problem.

..I see now it is the first thing checked in fscrypt_d_revalidate.

>> Should I just drop this hunk?  Unless you are confident it works as is, I
>> prefer to add this support in stages and keep negative dentries of
>> encrypted+casefold directories disabled for now.
>
> Unless I'm missing something, I think you're overcomplicating it.

Not overcomplicating. I'm just not familiar with fscrypt details enough to be
sure I could enable it.  But yes, it seems safe.

> It should
> just work if you don't go out of your way to prohibit this case.  I.e., just
> don't add the IS_ENCRYPTED(dir) check to generic_ci_d_revalidate().

I'll drop the check. And resend.

Thanks,

-- 
Gabriel Krisman Bertazi

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ