From patchwork Mon Dec 19 22:20:13 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Biggers X-Patchwork-Id: 9480801 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 866A9601C2 for ; Mon, 19 Dec 2016 22:21:14 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 77EE32837F for ; Mon, 19 Dec 2016 22:21:14 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 6CF7D284FC; Mon, 19 Dec 2016 22:21:14 +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.3 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM, 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 16AE62837F for ; Mon, 19 Dec 2016 22:21:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755189AbcLSWVM (ORCPT ); Mon, 19 Dec 2016 17:21:12 -0500 Received: from mail-it0-f67.google.com ([209.85.214.67]:36741 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754149AbcLSWVE (ORCPT ); Mon, 19 Dec 2016 17:21:04 -0500 Received: by mail-it0-f67.google.com with SMTP id n68so11929876itn.3 for ; Mon, 19 Dec 2016 14:21:04 -0800 (PST) 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=NAXf2n4T9XC5IhP5O99ar92kNViPKniMEIKn12lqI3Q=; b=uON5+OCDrsVSwCY0jDYLATBiNdqd2dWZyQTUx4gs4LDT9LOsJCa80MfKMKS1Bixghu jj4QSHX3ri9ghAishClQiXjzwj7VvN/kAxGnuQpgiXlXl5AhnIyr47Hs0xyH/BbWGy1z 2vbxo/wbFeO6PBeaCCEBhlwKxghSTZUhNZvFwdztFWVvC5wg+tfa0auETkpMMstQWJCy mfo5A34F6HiHIzEtpOoAGEjSOP30jMbmvHZ/Kbr1ITz2yKFkVLhDfX9RM/SJKRgrVVy5 P02qvWYGaohNnfYrdIgD+93VSoFD05JjaBW75bOCXXpzADhN6NAZJtcZQAwMKrh3ud8H oA4Q== 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=NAXf2n4T9XC5IhP5O99ar92kNViPKniMEIKn12lqI3Q=; b=KVgtvY+gpEqHimo9vEsDcNcGp0w8mRLs8C5e3cQV/U9hZPhVrAF0BEOupj7LtpZPUX DVUW6i4mpVNaNAE0ENTXuhyslTrJY27GsObYJM//LVR63eZKd8R7VxsdlUrxDU05Ngif M0BafSwBFKp6HvLtiXXsnfvlo2ijcZcyo6Lc/cz1cRNE0I9x6jH3wvPDhyHWArcNlZEs YdCB1rqv1SF7/jPjLG254chK2/x6ytoxwZ0+DR8Casu8nCVa9/STuaM20/vAKSSbFt1Z RrkIhBZJsKlrhKiVU7L31dH1GARn3WJsJ+G4B5a9auFOrON+DD47CKzmwdDF6bcMCgiC vcHg== X-Gm-Message-State: AKaTC00z7WC8bXdo5uzb3aj0VSUmdMZyWIzWl2Hi3D7nX1WGw8wUMk0eptDSDWK1mCx/qQ== X-Received: by 10.36.88.65 with SMTP id f62mr19721832itb.89.1482186063809; Mon, 19 Dec 2016 14:21:03 -0800 (PST) Received: from ebiggers-linuxstation.kir.corp.google.com ([100.119.30.131]) by smtp.gmail.com with ESMTPSA id g186sm7687106itb.21.2016.12.19.14.21.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 19 Dec 2016 14:21:03 -0800 (PST) From: Eric Biggers To: linux-fsdevel@vger.kernel.org Cc: "Theodore Y . Ts'o" , Jaegeuk Kim , Richard Weinberger , Eric Biggers Subject: [PATCH v2 2/5] fscrypt: fix renaming and linking special files Date: Mon, 19 Dec 2016 14:20:13 -0800 Message-Id: <1482186016-107643-2-git-send-email-ebiggers3@gmail.com> X-Mailer: git-send-email 2.8.0.rc3.226.g39d4020 In-Reply-To: <1482186016-107643-1-git-send-email-ebiggers3@gmail.com> References: <1482186016-107643-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-Virus-Scanned: ClamAV using ClamSMTP From: Eric Biggers Attempting to link a device node, named pipe, or socket file into an encrypted directory through rename(2) or link(2) always failed with EPERM. This happened because fscrypt_has_permitted_context() saw that the file was unencrypted and forbid creating the link. This behavior was unexpected because such files are never encrypted; only regular files, directories, and symlinks can be encrypted. To fix this, make fscrypt_has_permitted_context() always return true on special files. This will be covered by a test in my encryption xfstests patchset. Fixes: 9bd8212f981e ("ext4 crypto: add encryption policy and password salt support") Signed-off-by: Eric Biggers Reviewed-by: Richard Weinberger Cc: stable@vger.kernel.org --- fs/crypto/policy.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/fs/crypto/policy.c b/fs/crypto/policy.c index 5de0633..2e50cbc 100644 --- a/fs/crypto/policy.c +++ b/fs/crypto/policy.c @@ -198,6 +198,11 @@ int fscrypt_has_permitted_context(struct inode *parent, struct inode *child) if (!cops->is_encrypted(parent)) return 1; + /* No restrictions on file types which are never encrypted */ + if (!S_ISREG(child->i_mode) && !S_ISDIR(child->i_mode) && + !S_ISLNK(child->i_mode)) + return 1; + /* Encrypted directories must not contain unencrypted files */ if (!cops->is_encrypted(child)) return 0;