From patchwork Sun Apr 3 05:22:01 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Biggers X-Patchwork-Id: 8732921 Return-Path: X-Original-To: patchwork-linux-fsdevel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id CA1F0C0553 for ; Sun, 3 Apr 2016 05:24:49 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 0103E20251 for ; Sun, 3 Apr 2016 05:24:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 08E3A2022D for ; Sun, 3 Apr 2016 05:24:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752607AbcDCFXs (ORCPT ); Sun, 3 Apr 2016 01:23:48 -0400 Received: from mail-ig0-f194.google.com ([209.85.213.194]:35600 "EHLO mail-ig0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752476AbcDCFXp (ORCPT ); Sun, 3 Apr 2016 01:23:45 -0400 Received: by mail-ig0-f194.google.com with SMTP id ya17so7659257igc.2; Sat, 02 Apr 2016 22:23:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=rxojifaWy9NCCDEwRpfhA2NV/2jutnAf7J4WCQLuZUU=; b=mX4QVFlkCBZBw9rxFXwM3MesBOL9KQVOLMi+pRFREDnjbRPphqBqAXd23OOVg4E/Xp VVFowTVe47LS/4P++vSqfOlrwzZpuxnPstjB6CwGn0LyEQrI6feD3T+7Ldc9xhsJZewh vTdJtFz545hafo7mV2jJHREQxxHf4eWR5ZVFekYFC8p1RW647jJQn31J9MXiLHDwyh5U kheu+aj1YDxvF54CGURsA6OQpTdzQmZQYlB+vIhseMWuokDJIj7FxxjftjkuoVhZbt1/ h8X87JBCYO3Kw/WbRiEZ6LOnu6Fci90z7PnxSfuk8nHGo/T1jjljwmZPJ/wvLiJe4Vbu KW0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=rxojifaWy9NCCDEwRpfhA2NV/2jutnAf7J4WCQLuZUU=; b=CiOdJWinlwRdD+MjfbFellx7xaNbFIFMNAWPsgzMg2lz2oldEW95JrCxPk4UxN4FiW kaHUwas7frBbe9LWVvAZquLCj85DcS4F1Ff+BILFgLhrVzgMbVpnNzursAiSs+9NRQjR GFxWJnrZo6jh0LoM77uhQECJDrrENyw4FOL/MLJySBblKzAPaQhJoi97yD3AJZwjbgVd zxGIKLUallTbNd/oPNq1BJ/2S1ZbTXDRRuMgb8LM8xKo/KHGwen4wmA6m4ymJ9QkyMQl DAkUGCje7pOI/c6wM/lpDd9UnoTk3RbrXnjPgQ9HPUJz1Ax4qiC5wToYU6LdYjC7Kcyo zSmg== X-Gm-Message-State: AD7BkJK7vuDpSjyp3CpFcUOjXWMb+SN38dgxNUkBM77mlSoUDJj3NIno5S7HaQO/d3AAVQ== X-Received: by 10.50.118.103 with SMTP id kl7mr444147igb.59.1459661024715; Sat, 02 Apr 2016 22:23:44 -0700 (PDT) Received: from localhost.localdomain (c-24-7-245-123.hsd1.mn.comcast.net. [24.7.245.123]) by smtp.gmail.com with ESMTPSA id je6sm2914954igb.15.2016.04.02.22.23.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 02 Apr 2016 22:23:44 -0700 (PDT) From: Eric Biggers To: linux-fsdevel@vger.kernel.org Cc: linux-f2fs-devel@lists.sourceforge.net, linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, jaegeuk@kernel.org, tytso@mit.edu, mhalcrow@google.com, Eric Biggers Subject: [PATCH 10/13] fscrypto: restrict setting new policy to empty files and directories only Date: Sun, 3 Apr 2016 00:22:01 -0500 Message-Id: <1459660924-2960-11-git-send-email-ebiggers3@gmail.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1459660924-2960-1-git-send-email-ebiggers3@gmail.com> References: <1459660924-2960-1-git-send-email-ebiggers3@gmail.com> Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On f2fs, a user could create a regular file of small positive size and issue FS_IOC_SET_ENCRYPTION_POLICY to set its encryption policy. However, this did not behave as expected because the existing data was not actually encrypted by the ioctl. Fix this by only permitting an encryption policy to be created for empty regular files and directories. For a correct solution, it is necessary to conduct the operation under the inode lock; otherwise the inode's size might be changed concurrently. Signed-off-by: Eric Biggers --- fs/crypto/policy.c | 42 ++++++++++++++++++++++++++++++------------ 1 file changed, 30 insertions(+), 12 deletions(-) diff --git a/fs/crypto/policy.c b/fs/crypto/policy.c index 93244b5..cb5ba27 100644 --- a/fs/crypto/policy.c +++ b/fs/crypto/policy.c @@ -94,23 +94,41 @@ static int create_encryption_context_from_policy(struct inode *inode, int fscrypt_set_policy(struct inode *inode, const struct fscrypt_policy *policy) { + int ret = 0; + if (policy->version != 0) return -EINVAL; + inode_lock(inode); + if (!inode_has_encryption_context(inode)) { - if (!inode->i_sb->s_cop->empty_dir) - return -EOPNOTSUPP; - if (!inode->i_sb->s_cop->empty_dir(inode)) - return -ENOTEMPTY; - return create_encryption_context_from_policy(inode, policy); + /* A new policy may only be set on an empty directory or an + * empty regular file. */ + ret = -EINVAL; + if (S_ISDIR(inode->i_mode)) { + if (!inode->i_sb->s_cop->empty_dir) + ret = -EOPNOTSUPP; + else if (inode->i_sb->s_cop->empty_dir(inode)) + ret = 0; + else + ret = -ENOTEMPTY; + } else if (S_ISREG(inode->i_mode)) { + ret = -ENOTEMPTY; + if (inode->i_size == 0) + ret = 0; + } + if (!ret) { + ret = create_encryption_context_from_policy(inode, + policy); + } + } else if (!is_encryption_context_consistent_with_policy(inode, policy)) { + printk(KERN_WARNING + "%s: Policy inconsistent with encryption context\n", + __func__); + ret = -EINVAL; } - - if (is_encryption_context_consistent_with_policy(inode, policy)) - return 0; - - printk(KERN_WARNING "%s: Policy inconsistent with encryption context\n", - __func__); - return -EINVAL; + inode_unlock(inode); + return ret; } EXPORT_SYMBOL(fscrypt_set_policy);