linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Daniel Rosenberg <drosen@google.com>,
	Eric Biggers <ebiggers@kernel.org>,
	Ext4 Developers List <linux-ext4@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Gabriel Krisman Bertazi <krisman@collabora.com>,
	kernel-team@android.com, Paul Lawrence <paullawrence@google.com>
Subject: Re: [PATCH 1/2] ext4: Handle casefolding with encryption
Date: Fri, 19 Feb 2021 10:21:39 -0500	[thread overview]
Message-ID: <YC/Xg4I+2ppIQ2gW@mit.edu> (raw)
In-Reply-To: <01918C7B-9D9B-4BD8-8ED1-BA1CBF53CA95@dilger.ca>

On Wed, Feb 17, 2021 at 03:48:39PM -0700, Andreas Dilger wrote:
> It would be possible to detect if the encrypted/casefold+dirdata
> variant is in use, because the dirdata variant would have the 0x40
> bit set in the file_type byte.  It isn't possible to positively
> identify the "raw" non-dirdata variant, but the assumption would be
> if (rec_len >= round_up(name_len, 4) + 8) in an encrypted+casefold
> directory that the "raw" hash must be present in the dirent.

Consider a 4k directory directory block which has only three entries,
".", "..", and "a".  The directory entry for "a" will have a rec_len
substantially larger than name_len.

Fortunatelly, the "raw" non-dirdata variant case easily can be
detected.  If the directory has the encryption and casefold set, and
the 0x40 bit is not set, then raw must be present, assuming that the
directory block has not been corrupted (but if it's corrupted, all
bets are off).

	       	       		      	       - Ted
					       

  parent reply	other threads:[~2021-02-19 15:22 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-03  9:07 [PATCH 0/2] Reconcile Encryption and Casefolding in Ext4 Daniel Rosenberg
2021-02-03  9:07 ` [PATCH 1/2] ext4: Handle casefolding with encryption Daniel Rosenberg
     [not found]   ` <56BC7E2D-A303-45AE-93B6-D8921189F604@dilger.ca>
2021-02-03 16:31     ` Theodore Ts'o
2021-02-09 23:22       ` Theodore Ts'o
2021-02-10  3:03         ` Andreas Dilger
2021-02-10  4:03           ` Theodore Ts'o
2021-02-17  4:01             ` Daniel Rosenberg
2021-02-17 16:08               ` Theodore Ts'o
2021-02-17 22:48                 ` Andreas Dilger
2021-02-18 23:21                   ` Daniel Rosenberg
2021-02-26  5:14                     ` Andreas Dilger
2021-02-19 15:21                   ` Theodore Ts'o [this message]
2021-02-03  9:07 ` [PATCH 2/2] ext4: Optimize match for casefolded encrypted dirs Daniel Rosenberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YC/Xg4I+2ppIQ2gW@mit.edu \
    --to=tytso@mit.edu \
    --cc=adilger@dilger.ca \
    --cc=drosen@google.com \
    --cc=ebiggers@kernel.org \
    --cc=kernel-team@android.com \
    --cc=krisman@collabora.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paullawrence@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).