Received: by 10.223.185.116 with SMTP id b49csp4196352wrg; Tue, 13 Feb 2018 14:37:22 -0800 (PST) X-Google-Smtp-Source: AH8x225xOgFxPVkPPqMXOI6xUvWieZf4dq03Gb/fOGIrP8tJTNRIfpNGYBdshV/+N2olSYiUbL08 X-Received: by 10.98.93.9 with SMTP id r9mr2664293pfb.55.1518561442607; Tue, 13 Feb 2018 14:37:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518561442; cv=none; d=google.com; s=arc-20160816; b=mjJPGi4CALQnP0UZ/7PDzGGsy8C12XSMEBbJj8r4pYZvIIvpMpnLtot8FQ6PzPkHuv 2hmX1WBszsvVpCza7smXxhPo5SuSS85CmymnH1HqYF71OgtCBlvpYancbu4lXKf/6lxH DaqQ/5IIuxPQh3zdXJvtZ9JfoFmQ7/k7M8eW9Pev3XJySAuvE4icVflQfLglEpUWnua8 Kto8iCObKAGkKhpWcQZbdJYzRwYgShTIYksf8nYDiQgIUsqE08eOIXQFjkAx5sVaXP0g qVtSJLuCR9D7GRaVOmdU8+ZebNny+mksLhHphEYrnAaOghW5k7S03NJn3gQ+3BeN6ioA sRbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=lOPX5N0qroqPSFgKZuPeCrDMM/ikcZcpMBaO9r2f5sI=; b=jjkYE+G8GoG1c1G8PMpTbOOjmTOp19NjaWuaiPxB2tjeuCNkcqnW1TeKDGcqBm3k4t IsdLZN6PaRNbcpHhFgEON6YST7+7vsMMycHRs5Z0IPXZMhVX++FXgxlH297HfXZs8yH0 vSt/Pk/D1H5D/e+xG/qrmyQ9XoW4wOZdDk/0refOpqhR2T0RnKKzIF/pTGbWuAU6F1cH 97ATkxPMJ6i/Qa+lqHOVGJj1Sq32fLjDrKomOzdM+72WQfe8Mv4Nix1jH0qvXsCzj1b/ blN2IV/QdUKb6R0XA2XOrcBqPJDaOwtODQo4ysGqzp5LTFuEu2NBk58gZwgtP9+Y6Fwe aYaA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=QvOMV8d1; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u12si451526pfl.24.2018.02.13.14.37.04; Tue, 13 Feb 2018 14:37:22 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=QvOMV8d1; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966028AbeBMWgO (ORCPT + 99 others); Tue, 13 Feb 2018 17:36:14 -0500 Received: from mail-pg0-f67.google.com ([74.125.83.67]:38945 "EHLO mail-pg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965942AbeBMWgM (ORCPT ); Tue, 13 Feb 2018 17:36:12 -0500 Received: by mail-pg0-f67.google.com with SMTP id w17so920625pgv.6; Tue, 13 Feb 2018 14:36:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:date:message-id; bh=lOPX5N0qroqPSFgKZuPeCrDMM/ikcZcpMBaO9r2f5sI=; b=QvOMV8d1BTU/2xuexfC7IUfQUAvlUHqT2SPTMsaGtpmUlQWWG2MXT4tZt+NGWcoh4h fUyXYuwoLRneeuzzwkCot1GD5qhThaH91M7jMa8a5FC3qb8lOSI+4TQAuGHigo4o/Q28 97oQaeUwlDYLGsJ+mzD9BnNrr1tPclPT3rueJ/4AUSWMJTWwQAQzYtui7T3dd4cbM1QS HeOCuCygJ+fnUM2MKy/WrCL278cjs6A89v5uMXd9duNZ/RKju6kAmVEF7u0sP6WCOetB CqowsirTf3ZBK/prkRDG73qbrVulrNwjNF3HDlnvg075dyphADS9bjh+rS8rf4q5ojV3 qJ8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id; bh=lOPX5N0qroqPSFgKZuPeCrDMM/ikcZcpMBaO9r2f5sI=; b=Gl410xzuF5LS8+wcC5umu4e/9/nxW9iP67MK+2QcI8kXyzQq4W4XwGXGxaCok9sCPB PJsJg00Z6e1a5sRrgqzKzYH73fN+8yHDMjrfjG/U2f4mAb1nPSFTelYuz+2kHb+sX5X1 Zn4rHqMZvu44QEhIfVID15B4qjZ79CF9ln+I+Zx1Rxc2lcxzIwKhcN2rq9ezQSmB5iX1 mDqK091Nu1upTAAJGgzjArJiIa0VH6YJubfdQsm0wEVIPO07DzVJORB14D6sm8UNfYmU NImnFgd2Hp78YqdhwuZ/bC6Fosc64tZJLgPSrIJriyEk79FToCheZzo/J4Z78rvy5zEi oiyQ== X-Gm-Message-State: APf1xPAbb1UzLWkyDt4fS7Vuc8Qk1kOBSNpTUzOZ8BU36a/9jAIWH4SH 9dEh6HsIimhsrGMthzB8NEVNoQ== X-Received: by 10.101.69.67 with SMTP id x3mr2176354pgr.69.1518561371882; Tue, 13 Feb 2018 14:36:11 -0800 (PST) Received: from localhost (108-223-40-66.lightspeed.sntcca.sbcglobal.net. [108.223.40.66]) by smtp.gmail.com with ESMTPSA id i86sm7166704pfj.89.2018.02.13.14.36.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Feb 2018 14:36:10 -0800 (PST) From: Guenter Roeck To: Tyler Hicks Cc: ecryptfs@vger.kernel.org, linux-kernel@vger.kernel.org, Guenter Roeck , Al Viro Subject: [PATCH] ecryptfs: Restore support for both encrypted and unencrypted file names Date: Tue, 13 Feb 2018 14:36:08 -0800 Message-Id: <1518561368-8324-1-git-send-email-linux@roeck-us.net> X-Mailer: git-send-email 2.7.4 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit 88ae4ab9802e ("ecryptfs_lookup(): try either only encrypted or plaintext name") was supposed to fix a situation where two files with the same name and same inode could be created in ecryptfs. One of those files had an encrypted file name, the other file name was unencrypted. After commit 88ae4ab9802e, having a mix of encrypted and unencrypted file names is no longer supposed to be possible. However, that is not the case. The only difference is that it is now even easier to create a situation where two files with the same name coexist (one encrypted and the other not encrypted). In practice, this looks like the following (files created with v4.14.12). ecryptfs mounted with file name encryption enabled: $ ls -li total 48 5252822 -rw-rw-r-- 1 groeck groeck 10 Jan 20 13:02 myfile 5252822 -rw-rw-r-- 1 groeck groeck 10 Jan 20 13:02 myfile 5252824 -rw-rw-r-- 1 groeck groeck 10 Jan 20 15:36 myfile2 5252824 -rw-rw-r-- 1 groeck groeck 10 Jan 20 15:36 myfile2 $ grep . * myfile:encrypted myfile:encrypted myfile2:encrypted myfile2:encrypted $ ls -li total 48 5252824 -rw-rw-r-- 1 groeck groeck 10 Jan 20 15:36 ECRYPTFS_FNEK_ENCRYPTED.FWbF9U6H6L6ekEZYGWnkfR4wMiyeTVoCeVun.BU8Zu5-njbcIPoApxk7-E-- 5252822 -rw-rw-r-- 1 groeck groeck 10 Jan 20 13:02 ECRYPTFS_FNEK_ENCRYPTED.FWbF9U6H6L6ekEZYGWnkfR4wMiyeTVoCeVunt0fda7t9YCtJ70cm911yZ--- 5252817 -rw-rw-r-- 1 groeck groeck 12 Jan 20 12:52 myfile 5252827 -rw-rw-r-- 1 groeck groeck 12 Jan 20 15:37 myfile2 $ grep . * ECRYPTFS_FNEK_ENCRYPTED.FWbF9U6H6L6ekEZYGWnkfR4wMiyeTVoCeVun.BU8Zu5-njbcIPoApxk7-E--:encrypted ECRYPTFS_FNEK_ENCRYPTED.FWbF9U6H6L6ekEZYGWnkfR4wMiyeTVoCeVunt0fda7t9YCtJ70cm911yZ---:encrypted myfile:unencrypted myfile2:unencrypted Creating a file with file name encryption disabled and remounting with file name encryption enabled results in the following. $ ls -li ls: cannot access 'myfile3': No such file or directory total 48 5252822 -rw-rw-r-- 1 groeck groeck 10 Jan 20 13:02 myfile 5252822 -rw-rw-r-- 1 groeck groeck 10 Jan 20 13:02 myfile 5252824 -rw-rw-r-- 1 groeck groeck 10 Jan 20 15:36 myfile2 5252824 -rw-rw-r-- 1 groeck groeck 10 Jan 20 15:36 myfile2 ? -????????? ? ? ? ? ? myfile3 Prior to commit 88ae4ab9802e, the file system had to be mounted with encrypted file names first to create a file, then the same had to be repeated after mounting with unencrypted file names. Now the duplicate files can be created both ways (unencrypted _or_ encrypted first). The only real difference is that it is no longer possible to have a _working_ combination of encrypted and unencrypted file names. In other words, commit 88ae4ab9802e results in reduced functionality with no benefit whatsoever. Restore ability to have a mix of unencrypted and encrypted files. This effectively reverts commit 88ae4ab9802e, but the code is now better readable since it avoids a number of goto statements. Cc: Al Viro Signed-off-by: Guenter Roeck --- fs/ecryptfs/inode.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/fs/ecryptfs/inode.c b/fs/ecryptfs/inode.c index 847904aa63a9..14a5c096ead6 100644 --- a/fs/ecryptfs/inode.c +++ b/fs/ecryptfs/inode.c @@ -392,11 +392,11 @@ static struct dentry *ecryptfs_lookup(struct inode *ecryptfs_dir_inode, int rc = 0; lower_dir_dentry = ecryptfs_dentry_to_lower(ecryptfs_dentry->d_parent); - + lower_dentry = lookup_one_len_unlocked(name, lower_dir_dentry, len); mount_crypt_stat = &ecryptfs_superblock_to_private( ecryptfs_dentry->d_sb)->mount_crypt_stat; - if (mount_crypt_stat - && (mount_crypt_stat->flags & ECRYPTFS_GLOBAL_ENCRYPT_FILENAMES)) { + if (IS_ERR(lower_dentry) && + (mount_crypt_stat->flags & ECRYPTFS_GLOBAL_ENCRYPT_FILENAMES)) { rc = ecryptfs_encrypt_and_encode_filename( &encrypted_and_encoded_name, &len, mount_crypt_stat, name, len); @@ -405,10 +405,10 @@ static struct dentry *ecryptfs_lookup(struct inode *ecryptfs_dir_inode, "filename; rc = [%d]\n", __func__, rc); return ERR_PTR(rc); } - name = encrypted_and_encoded_name; + lower_dentry = lookup_one_len_unlocked( + encrypted_and_encoded_name, lower_dir_dentry, len); } - lower_dentry = lookup_one_len_unlocked(name, lower_dir_dentry, len); if (IS_ERR(lower_dentry)) { ecryptfs_printk(KERN_DEBUG, "%s: lookup_one_len() returned " "[%ld] on lower_dentry = [%s]\n", __func__, -- 2.7.4