Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp1663pxu; Wed, 2 Dec 2020 13:11:36 -0800 (PST) X-Google-Smtp-Source: ABdhPJz+4PUosBnEGdjjdWx68hfXJMy0M+Afe5O17IZ7GKdBq9MU2cBt87MpoVayovp3bG7YeaNC X-Received: by 2002:a17:906:77c5:: with SMTP id m5mr1584967ejn.424.1606943496570; Wed, 02 Dec 2020 13:11:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606943496; cv=none; d=google.com; s=arc-20160816; b=EHKc6Ax9tVJX+BLeeFYfkzUkYoVn2W1BUNzn1CEm2QsLM3EW/ELSknmP6MGuB3pOCB xWxfariF1+adu0u4gSECKEhUOrC2fA6f3d7UYiCoq3X3V+k9RJIvOZJ4q1IHxEiJ04I+ KwSbvkaVM2Su6/4nU/85LxEa8tA1tngNzDnTKqNuGKJDvylQhvSsuycXFYXCExTwNCt5 LXkl9SjPoPTuDKaTvS3DXhSN5pmIKZl0oMJjszvvr6Bvna9rEWqQ2huhePoIOdeu4twY kcYt1LxjtGX9Zs8No4IlqlyO+MQ+b12mXvsVPTCjsPuMsRCeOghXdGPaX8fcYA9JDeS1 InZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:dkim-signature:date; bh=5iYedmtrVjqIqbVPNv+CJa7K980k0yraUJgrzA1DCnY=; b=RsQ28eDhVnqwSTZpPzARjkY11eD31M43kM/n43HqtgfnMUV2swgJ8DvH0P/EfZ1YNv Zsi26Ri8z6AyBlbSjkFZRCM7xTt+RFFJBdVwBZqkf/gqSb+CH+r+HjvaIo2u3ns+TeTJ ICBsShPeoj1pGGjBQ0BXGQEX3//HWtdwfZwD2Zk0RdHsM2/59TS+9jnJwyGIyuM26XEA m6NXXt0JVYyUKWn0L/opy2wLEgpIwTMO+jt/zMX2PsNKb8bpwn1fliefUP+sYmmXuVKH KggTwp+HPpkDok4jRxadqBSqSooFEbrF05+jko0M9IwV88af8UFaVp2fXuAlI9YXK8BM XcLQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="EZNH/dFH"; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dx21si822904ejb.197.2020.12.02.13.11.11; Wed, 02 Dec 2020 13:11:36 -0800 (PST) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="EZNH/dFH"; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728052AbgLBVIi (ORCPT + 99 others); Wed, 2 Dec 2020 16:08:38 -0500 Received: from mail.kernel.org ([198.145.29.99]:43092 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726669AbgLBVIh (ORCPT ); Wed, 2 Dec 2020 16:08:37 -0500 Date: Wed, 2 Dec 2020 13:07:53 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1606943277; bh=z7aM84uoaVRXDrRTKXVTwdXKK69LzrzJ1yjZQqo3344=; h=From:To:Cc:Subject:References:In-Reply-To:From; b=EZNH/dFHxK112U8asIp9Tyi1NmmUiP3WZ8jKeTdDrVskZASdlAR/S1wDBS3JHVR6j 3z+pV6U+lXcVEMTt2lE9kKMNWS54qhtKYSyZJ1y/OwNcNYH+2zcwZXXoqTyEQWwNpS ZkQymrXas2DHQb0qKTLFm0/3JkDC9FC7r39gbgLcj5+c/ZI+idYLTm/7F/T7NVWXvO q4jhvHNzRrrww4sIAKh0IFFHKFWbaAxr6ln+yidV6vyDxnLQUewpajhRHkcPDimBi2 +7L2ec88F9TKg8MI6yFF0aM//oPxYTD/cl8b1g/XUOyYDXPhM0kBavcUQeTmQOIU7o p9GqnFEnkOM7g== From: Eric Biggers To: linux-fscrypt@vger.kernel.org Cc: linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-mtd@lists.infradead.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH 0/9] Allow deleting files with unsupported encryption policy Message-ID: References: <20201125002336.274045-1-ebiggers@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201125002336.274045-1-ebiggers@kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Tue, Nov 24, 2020 at 04:23:27PM -0800, Eric Biggers wrote: > Currently it's impossible to delete files that use an unsupported > encryption policy, as the kernel will just return an error when > performing any operation on the top-level encrypted directory, even just > a path lookup into the directory or opening the directory for readdir. > > It's desirable to return errors for most operations on files that use an > unsupported encryption policy, but the current behavior is too strict. > We need to allow enough to delete files, so that people can't be stuck > with undeletable files when downgrading kernel versions. That includes > allowing directories to be listed and allowing dentries to be looked up. > > This series fixes this (on ext4, f2fs, and ubifs) by treating an > unsupported encryption policy in the same way as "key unavailable" in > the cases that are required for a recursive delete to work. > > The actual fix is in patch 9, so see that for more details. > > Patches 1-8 are cleanups that prepare for the actual fix by removing > direct use of fscrypt_get_encryption_info() by filesystems. > > This patchset applies to branch "master" (commit 4a4b8721f1a5) of > https://git.kernel.org/pub/scm/fs/fscrypt/fscrypt.git. > > Eric Biggers (9): > ext4: remove ext4_dir_open() > f2fs: remove f2fs_dir_open() > ubifs: remove ubifs_dir_open() > ext4: don't call fscrypt_get_encryption_info() from dx_show_leaf() > fscrypt: introduce fscrypt_prepare_readdir() > fscrypt: move body of fscrypt_prepare_setattr() out-of-line > fscrypt: move fscrypt_require_key() to fscrypt_private.h > fscrypt: unexport fscrypt_get_encryption_info() > fscrypt: allow deleting files with unsupported encryption policy > > fs/crypto/fname.c | 8 +++- > fs/crypto/fscrypt_private.h | 28 ++++++++++++++ > fs/crypto/hooks.c | 16 +++++++- > fs/crypto/keysetup.c | 20 ++++++++-- > fs/crypto/policy.c | 22 +++++++---- > fs/ext4/dir.c | 16 ++------ > fs/ext4/namei.c | 10 +---- > fs/f2fs/dir.c | 10 +---- > fs/ubifs/dir.c | 11 +----- > include/linux/fscrypt.h | 75 +++++++++++++++++++------------------ > 10 files changed, 126 insertions(+), 90 deletions(-) > > > base-commit: 4a4b8721f1a5e4b01e45b3153c68d5a1014b25de Any more comments on this patch series? - Eric