From patchwork Tue Jun 13 23:47:54 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Biggers X-Patchwork-Id: 9785005 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 1B0C060244 for ; Tue, 13 Jun 2017 23:49:14 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0D3462684F for ; Tue, 13 Jun 2017 23:49:14 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 01DEC27FB6; Tue, 13 Jun 2017 23:49:13 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id AF56F2684F for ; Tue, 13 Jun 2017 23:49:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753646AbdFMXtK (ORCPT ); Tue, 13 Jun 2017 19:49:10 -0400 Received: from mail-pf0-f195.google.com ([209.85.192.195]:33999 "EHLO mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752456AbdFMXtJ (ORCPT ); Tue, 13 Jun 2017 19:49:09 -0400 Received: by mail-pf0-f195.google.com with SMTP id d5so11698526pfe.1; Tue, 13 Jun 2017 16:49:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=KMAyMggFDikzRkkLCNzfm4ff+JklveDqLkp5O0v/NA4=; b=TxVPAFXglGDMfT1uAycV4kcxsaKIHsK3WEgbHFUJf2hrDu4qwOLy3/1a+4Z/XNVX+I Izd86S1+U4o7RcUQ1v7JPlMSAlWr1X7Xn0IOxhI2YjiQ2/vZZitbxQRIN3nFy0kt3nxi yVBLKKZEpotogMeucjYQCzaGIFo1OhYoDzI6fogj7rk1KjAQ0jmt/G3cKjqRAghUvN5p vPbK2YmcwxwBC7XEWNGmVx7HXyttNyhHsrszZdUN3FaojwVH7zsaevZU0e87fIR4bzJ/ erbxAutjz3V6cRAvZQ3Xgw7eBM5Cu84wQhH/OSFfCloG10NHtHx67UqwP0gpldiBJqEp 0uKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=KMAyMggFDikzRkkLCNzfm4ff+JklveDqLkp5O0v/NA4=; b=BJ/3ohthoZXauDbXAChb92P2Y4gHyP87dlVKiaxTRXv084MjmzCRuNlbW7RbDogIpi 9v5QriJIN8bms9HB4TF6GPwQ2e+H6P6d2bBSfLCkBWZzjso851VXnqZEbKsTaljughEh lQ6qXvhpeqtykWHS6JIYOcfcms9TfaPiSJlW9Iqs1qnqM3L8cP62vV4hJwu3ea7vWWWP 9WjqTZcSfGtMWRWI2jbaYPMMPCQUbzTV4r66ZVmkm3s2eh5V2cYAu8mpXlrlDdI0jmLV kuppJ0OGTJvdNiB81BdPNq5wA/C8Vybxop0Y+ZiIJ++Nml5LebZ1wqWZ/6klwYCU7RA9 a/vQ== X-Gm-Message-State: AKS2vOyfkwyui+DsNKwdFaVEFqF2MMMLugBgc8WTMXqlrorjgP5QVaAR 0i2M+nXjjXUpTm/wWbnBjA== X-Received: by 10.84.128.68 with SMTP id 62mr1987870pla.184.1497397748374; Tue, 13 Jun 2017 16:49:08 -0700 (PDT) Received: from ebiggers-linuxstation.kir.corp.google.com ([100.66.174.81]) by smtp.gmail.com with ESMTPSA id h67sm27746603pfj.55.2017.06.13.16.49.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 13 Jun 2017 16:49:07 -0700 (PDT) From: Eric Biggers To: linux-fscrypt@vger.kernel.org Cc: Theodore Ts'o , linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-mtd@lists.infradead.org, Eric Biggers Subject: [PATCH 2/3] f2fs: require key for truncate(2) of encrypted file Date: Tue, 13 Jun 2017 16:47:54 -0700 Message-Id: <20170613234755.111167-3-ebiggers3@gmail.com> X-Mailer: git-send-email 2.13.1.508.gb3defc5cc-goog In-Reply-To: <20170613234755.111167-1-ebiggers3@gmail.com> References: <20170613234755.111167-1-ebiggers3@gmail.com> Sender: linux-fscrypt-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Eric Biggers Currently, filesystems allow truncate(2) on an encrypted file without the encryption key. However, it's impossible to correctly handle the case where the size being truncated to is not a multiple of the filesystem block size, because that would require decrypting the final block, zeroing the part beyond i_size, then encrypting the block. As other modifications to encrypted file contents are prohibited without the key, just prohibit truncate(2) as well, making it fail with ENOKEY. Signed-off-by: Eric Biggers Acked-by: Chao Yu --- fs/f2fs/file.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index 61af721329fa..be0b32bd1297 100644 --- a/fs/f2fs/file.c +++ b/fs/f2fs/file.c @@ -682,9 +682,13 @@ int f2fs_setattr(struct dentry *dentry, struct iattr *attr) return err; if (attr->ia_valid & ATTR_SIZE) { - if (f2fs_encrypted_inode(inode) && - fscrypt_get_encryption_info(inode)) - return -EACCES; + if (f2fs_encrypted_inode(inode)) { + err = fscrypt_get_encryption_info(inode); + if (err) + return err; + if (!fscrypt_has_encryption_key(inode)) + return -ENOKEY; + } if (attr->ia_size <= i_size_read(inode)) { truncate_setsize(inode, attr->ia_size);