All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers3@gmail.com>
To: linux-fscrypt@vger.kernel.org
Cc: hashimoto@chromium.org, Gwendal Grignou <gwendal@chromium.org>,
	"Theodore Y . Ts'o" <tytso@mit.edu>,
	Eric Biggers <ebiggers@google.com>,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-mtd@lists.infradead.org, Jaegeuk Kim <jaegeuk@kernel.org>,
	linux-ext4@vger.kernel.org, kinaba@chromium.org
Subject: [PATCH 0/6] fscrypt: fixes for presentation of long encrypted filenames
Date: Mon, 24 Apr 2017 10:00:07 -0700	[thread overview]
Message-ID: <20170424170013.85175-1-ebiggers3@gmail.com> (raw)

From: Eric Biggers <ebiggers@google.com>

This series fixes the bugs that have been identified with how filesystems handle
presenting long encrypted filenames without the key.

Patch 1 is Jaegeuk's fix to make f2fs start checking the ciphertext portion of
the digested names.  I made one change to this patch which is that to determine
whether we should use the hash from the fscrypt_name structure rather than
compute the hash, we should check for 'disk_name.name' being NULL rather than
'hash' being nonzero, since 0 is a valid hash value.

Patch 2 fixes the bug found on Chrome OS where the wrong part of the ciphertext
was included in the digested names, causing collisions and undeletable files.

Patches 3-6 clean things up to be less insane and confusing, e.g. by introducing
a shared function for name matching and a struct to represent a digested name.

Patches 1-2 will need to be backported and I think they should be merged into
4.12 through the fscrypt tree.  The other patches are nice to have but it's not
a big deal if they need to wait for next cycle.

This patch series leaves out UBIFS; it can be changed to use the common matching
function once available, if desired.

Eric Biggers (5):
  fscrypt: avoid collisions when presenting long encrypted filenames
  fscrypt: introduce helper function for filename matching
  ext4: switch to using fscrypt_match_name()
  f2fs: switch to using fscrypt_match_name()
  ext4: clean up ext4_match() and callers

Jaegeuk Kim (1):
  f2fs: check entire encrypted bigname when finding a dentry

 fs/crypto/fname.c               |  90 +++++++++++++++++++++++++++--------
 fs/crypto/fscrypt_private.h     |   2 -
 fs/ext4/namei.c                 | 103 ++++++++++++----------------------------
 fs/f2fs/dir.c                   |  25 ++--------
 fs/f2fs/f2fs.h                  |   3 +-
 fs/f2fs/hash.c                  |   7 ++-
 fs/f2fs/inline.c                |   4 +-
 include/linux/fscrypt_notsupp.h |   9 ++++
 include/linux/fscrypt_supp.h    |  78 ++++++++++++++++++++++++++++++
 9 files changed, 202 insertions(+), 119 deletions(-)

-- 
2.12.2.816.g2cccc81164-goog


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers3@gmail.com>
To: linux-fscrypt@vger.kernel.org
Cc: "Theodore Y . Ts'o" <tytso@mit.edu>,
	Jaegeuk Kim <jaegeuk@kernel.org>,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-ext4@vger.kernel.org, linux-mtd@lists.infradead.org,
	Gwendal Grignou <gwendal@chromium.org>,
	hashimoto@chromium.org, kinaba@chromium.org,
	Eric Biggers <ebiggers@google.com>
Subject: [PATCH 0/6] fscrypt: fixes for presentation of long encrypted filenames
Date: Mon, 24 Apr 2017 10:00:07 -0700	[thread overview]
Message-ID: <20170424170013.85175-1-ebiggers3@gmail.com> (raw)

From: Eric Biggers <ebiggers@google.com>

This series fixes the bugs that have been identified with how filesystems handle
presenting long encrypted filenames without the key.

Patch 1 is Jaegeuk's fix to make f2fs start checking the ciphertext portion of
the digested names.  I made one change to this patch which is that to determine
whether we should use the hash from the fscrypt_name structure rather than
compute the hash, we should check for 'disk_name.name' being NULL rather than
'hash' being nonzero, since 0 is a valid hash value.

Patch 2 fixes the bug found on Chrome OS where the wrong part of the ciphertext
was included in the digested names, causing collisions and undeletable files.

Patches 3-6 clean things up to be less insane and confusing, e.g. by introducing
a shared function for name matching and a struct to represent a digested name.

Patches 1-2 will need to be backported and I think they should be merged into
4.12 through the fscrypt tree.  The other patches are nice to have but it's not
a big deal if they need to wait for next cycle.

This patch series leaves out UBIFS; it can be changed to use the common matching
function once available, if desired.

Eric Biggers (5):
  fscrypt: avoid collisions when presenting long encrypted filenames
  fscrypt: introduce helper function for filename matching
  ext4: switch to using fscrypt_match_name()
  f2fs: switch to using fscrypt_match_name()
  ext4: clean up ext4_match() and callers

Jaegeuk Kim (1):
  f2fs: check entire encrypted bigname when finding a dentry

 fs/crypto/fname.c               |  90 +++++++++++++++++++++++++++--------
 fs/crypto/fscrypt_private.h     |   2 -
 fs/ext4/namei.c                 | 103 ++++++++++++----------------------------
 fs/f2fs/dir.c                   |  25 ++--------
 fs/f2fs/f2fs.h                  |   3 +-
 fs/f2fs/hash.c                  |   7 ++-
 fs/f2fs/inline.c                |   4 +-
 include/linux/fscrypt_notsupp.h |   9 ++++
 include/linux/fscrypt_supp.h    |  78 ++++++++++++++++++++++++++++++
 9 files changed, 202 insertions(+), 119 deletions(-)

-- 
2.12.2.816.g2cccc81164-goog

             reply	other threads:[~2017-04-24 17:00 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-24 17:00 Eric Biggers [this message]
2017-04-24 17:00 ` [PATCH 0/6] fscrypt: fixes for presentation of long encrypted filenames Eric Biggers
2017-04-24 17:00 ` [PATCH 1/6] f2fs: check entire encrypted bigname when finding a dentry Eric Biggers
2017-04-25  0:10   ` Jaegeuk Kim
2017-05-03  2:56     ` Eric Biggers
2017-05-03  4:21       ` Jaegeuk Kim
2017-04-30  6:19   ` [1/6] " Theodore Ts'o
2017-04-24 17:00 ` [PATCH 2/6] fscrypt: avoid collisions when presenting long encrypted filenames Eric Biggers
2017-04-24 17:00   ` Eric Biggers
2017-04-30  6:19   ` [2/6] " Theodore Ts'o
2017-04-24 17:00 ` [PATCH 3/6] fscrypt: introduce helper function for filename matching Eric Biggers
2017-04-24 17:00   ` Eric Biggers
2017-04-28 21:18   ` Eric Biggers
2017-04-30  6:20   ` [3/6] " Theodore Ts'o
2017-04-24 17:00 ` [PATCH 4/6] ext4: switch to using fscrypt_match_name() Eric Biggers
2017-04-24 17:00   ` Eric Biggers
2017-04-30  6:21   ` [4/6] " Theodore Ts'o
2017-04-24 17:00 ` [PATCH 5/6] f2fs: " Eric Biggers
2017-04-24 17:00   ` Eric Biggers
2017-04-25  0:16   ` Jaegeuk Kim
2017-04-25 13:37   ` Richard Weinberger
2017-04-25 17:46     ` Eric Biggers
2017-04-25 17:46       ` Eric Biggers
2017-04-25 19:22       ` Richard Weinberger
2017-04-25 19:22         ` Richard Weinberger
2017-04-25 20:58         ` Eric Biggers
2017-04-25 21:03           ` Richard Weinberger
2017-04-30  6:21   ` [5/6] " Theodore Ts'o
2017-04-24 17:00 ` [PATCH 6/6] ext4: clean up ext4_match() and callers Eric Biggers
2017-04-24 17:00   ` Eric Biggers
2017-04-30  6:22   ` [6/6] " Theodore Ts'o

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=20170424170013.85175-1-ebiggers3@gmail.com \
    --to=ebiggers3@gmail.com \
    --cc=ebiggers@google.com \
    --cc=gwendal@chromium.org \
    --cc=hashimoto@chromium.org \
    --cc=jaegeuk@kernel.org \
    --cc=kinaba@chromium.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=tytso@mit.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.