From patchwork Tue Jun 13 23:47:53 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Biggers X-Patchwork-Id: 9784999 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 205E360244 for ; Tue, 13 Jun 2017 23:49:09 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 131262684F for ; Tue, 13 Jun 2017 23:49:09 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 07E8C27FB6; Tue, 13 Jun 2017 23:49:09 +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 B6EBC2684F for ; Tue, 13 Jun 2017 23:49:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753382AbdFMXtI (ORCPT ); Tue, 13 Jun 2017 19:49:08 -0400 Received: from mail-pf0-f194.google.com ([209.85.192.194]:33982 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752456AbdFMXtH (ORCPT ); Tue, 13 Jun 2017 19:49:07 -0400 Received: by mail-pf0-f194.google.com with SMTP id d5so11698400pfe.1; Tue, 13 Jun 2017 16:49:06 -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=pYIsrKmXLCdC08W7MF/uDDKwGbT3HfYzVTawel61SKs=; b=mevH1CI0JGdUddU0NGQEiFlhtgGYznoA7ciNbOFQZERYMYGQnTL6pycJO25oBvI/RF YDOAu0AO0Z3OFh3p7cQB30/k3oVkCf9rqIINielKIGkrUs/K2PjB4b0DoNMcTQPcDAG1 gWkgWgpiUHyGBOSqzuCW79JNQwmj2UiVgYU1Aczmoind+Xk+0jD996cm0xgbNCeWMpfZ YaTxkgiVmys5aCbHb54/ijtI/SGdgCKJfAc0QfDy98GQ4esZC6iN95ewBzZ8OQ6j0Ah5 hRamOHD3D2OyAY9zKqTIE+uLA5PGhckF65UC/3y4xFDTWeA1zo8EaY+OV1jT9N99WLCD AnXw== 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=pYIsrKmXLCdC08W7MF/uDDKwGbT3HfYzVTawel61SKs=; b=AfAOu+FH4Rrvl7ZD4b55cP9mP7kF3liE8r5G2osLdTQWMkLlZp41MdJIsDYX1/FApR fPxoEHuCZoQ59M93J3Rjk6lccfU1zVsdEN7sYgh/gBdqaLuwXoR9VJoMU0EeUwmq2IC9 a/9L+/Qy067/znGo8WQlNFtmr6xnnGgxyLHyksbCNxcy8wFbmVxEovSUILUvX4RKQCkr 2yR0a5qgb3P+3f2Zo5OWDJBFLIr0oZGcjqOS54sU+kN9A1kAgGDgRdmgajzhK7sxObba StN4a4iPStr2GfolBusAJQ/xLEWIC0pB++4mykkPDYBGuHJh5it+nPLApRYQ0CFiH9wz xtIQ== X-Gm-Message-State: AKS2vOwSbIFSOWPvlfxI1EhoN2or3MKTdT4tvFqLnD9C08JSRwbc2ZcY IhpJWvOX3cL4ma9o/XYBLw== X-Received: by 10.99.96.9 with SMTP id u9mr1670789pgb.97.1497397746157; Tue, 13 Jun 2017 16:49:06 -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.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 13 Jun 2017 16:49:05 -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 1/3] ext4: require key for truncate(2) of encrypted file Date: Tue, 13 Jun 2017 16:47:53 -0700 Message-Id: <20170613234755.111167-2-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/ext4/inode.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 5cf82d03968c..baf8630de6a5 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -5307,6 +5307,14 @@ int ext4_setattr(struct dentry *dentry, struct iattr *attr) loff_t oldsize = inode->i_size; int shrink = (attr->ia_size <= inode->i_size); + if (ext4_encrypted_inode(inode)) { + error = fscrypt_get_encryption_info(inode); + if (error) + return error; + if (!fscrypt_has_encryption_key(inode)) + return -ENOKEY; + } + if (!(ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS))) { struct ext4_sb_info *sbi = EXT4_SB(inode->i_sb);