From patchwork Tue Jun 13 23:47:55 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Biggers X-Patchwork-Id: 9785007 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 818EC60244 for ; Tue, 13 Jun 2017 23:49:15 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 743D02684F for ; Tue, 13 Jun 2017 23:49:15 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 691B527FB6; Tue, 13 Jun 2017 23:49:15 +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 0E1D32684F for ; Tue, 13 Jun 2017 23:49:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753239AbdFMXtO (ORCPT ); Tue, 13 Jun 2017 19:49:14 -0400 Received: from mail-pg0-f68.google.com ([74.125.83.68]:35844 "EHLO mail-pg0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753624AbdFMXtK (ORCPT ); Tue, 13 Jun 2017 19:49:10 -0400 Received: by mail-pg0-f68.google.com with SMTP id v18so21062058pgb.3; Tue, 13 Jun 2017 16:49:10 -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=g7XMDrIRETObva7oF98FpxQnb50bIXhr7zW0aAPN5k4=; b=mw9iwoF6Ql8bCELbmQyjyAxQn1jkeZO50/WLj//E9CxS3KVZF3G11dpTflU30pyAvv pOcKZ9PV4HTSKCo7aRVzlb+Whhv6UuC8r71v+sYkf71hi+ul4hg5aLzPqi9d5xsWtlbH 9myusyOCZpxkY6TfZ3l3QIRo4AasT8aP6NKtjgqZVmJKyNEO2sQY4VDMy5zEHtfoCX2n 8fbL6+EwHvm+TB7N30twvXBXhEkkJrj9DHZljLtLdtDIKvszqQaNK4JuR4Cxjb+3DF7o BH0uuMCy4eeCs4hQSpF1wjoGk6r/H9VLsQNPZ+ksLs0w1aG574WuARqRxZ33K4bQTB93 NvnA== 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=g7XMDrIRETObva7oF98FpxQnb50bIXhr7zW0aAPN5k4=; b=B5mvxJTl2xoq+FVQ7Fx/BY3Un+rPAYrm9QMA3/iPhX4bzbuBk84skF6x1/NSbX3rKN WWdYo9ID4aizrxP51468PdchH+Z6GwFM0KCrYyaNJUCtFyOQjFm3jiFZc09BhWn9fKRd Eduuwfa2hh+EaAMvdGsPneqrqgS5yjCBZXMK8cdqBOegSFZ6NCDUOqDmFAXoXPR/euqU aVNVwfVifxZxCsXLKSTbONvAByAhADCddgdOZQrjkBGZ2JbdNOGw/Y5+tMgJec60wGJk Q12UMOmvzxRST82/VpPBVaFc3827sEjY0Hbw9Pvn3f3NNKarAEbtUU9q2r+XeXseLYPC NGsw== X-Gm-Message-State: AKS2vOxqWM52Kq+yl1NjtyXo2Qy/sDG8V47lZiHSS9uwDwu6msjWJDOP O4n4zCiBkX2kXCywYe+Esw== X-Received: by 10.84.133.100 with SMTP id 91mr1987881plf.106.1497397749443; Tue, 13 Jun 2017 16:49:09 -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.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 13 Jun 2017 16:49:08 -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 3/3] ubifs: require key for truncate(2) of encrypted file Date: Tue, 13 Jun 2017 16:47:55 -0700 Message-Id: <20170613234755.111167-4-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 --- fs/ubifs/file.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/fs/ubifs/file.c b/fs/ubifs/file.c index 2cda3d67e2d0..ee3ff4c6bf4a 100644 --- a/fs/ubifs/file.c +++ b/fs/ubifs/file.c @@ -1284,6 +1284,14 @@ int ubifs_setattr(struct dentry *dentry, struct iattr *attr) if (err) return err; + if (ubifs_crypt_is_encrypted(inode) && (attr->ia_valid & ATTR_SIZE)) { + err = fscrypt_get_encryption_info(inode); + if (err) + return err; + if (!fscrypt_has_encryption_key(inode)) + return -ENOKEY; + } + if ((attr->ia_valid & ATTR_SIZE) && attr->ia_size < inode->i_size) /* Truncation to a smaller size */ err = do_truncation(c, inode, attr);