From patchwork Wed Feb 15 19:04:44 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Colin Ian King X-Patchwork-Id: 141391 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from chlorine.canonical.com (chlorine.canonical.com [91.189.94.204]) by ozlabs.org (Postfix) with ESMTP id 5EDD01007D6 for ; Thu, 16 Feb 2012 06:05:03 +1100 (EST) Received: from localhost ([127.0.0.1] helo=chlorine.canonical.com) by chlorine.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1Rxk9x-0002Ym-8K; Wed, 15 Feb 2012 19:04:57 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by chlorine.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1Rxk9l-0002Xd-97 for kernel-team@lists.ubuntu.com; Wed, 15 Feb 2012 19:04:45 +0000 Received: from cpc19-craw6-2-0-cust5.croy.cable.virginmedia.com ([77.102.228.6] helo=localhost) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1Rxk9l-00033u-61 for kernel-team@lists.ubuntu.com; Wed, 15 Feb 2012 19:04:45 +0000 From: Colin King To: kernel-team@lists.ubuntu.com Subject: [PATCH 1/1] Ban ecryptfs over ecryptfs Date: Wed, 15 Feb 2012 19:04:44 +0000 Message-Id: <1329332684-21429-2-git-send-email-colin.king@canonical.com> X-Mailer: git-send-email 1.7.9 In-Reply-To: <1329332684-21429-1-git-send-email-colin.king@canonical.com> References: <1329332684-21429-1-git-send-email-colin.king@canonical.com> X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.13 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: kernel-team-bounces@lists.ubuntu.com Errors-To: kernel-team-bounces@lists.ubuntu.com From: Colin Ian King This is a seriously simplified patch from Eric Sandeen; copy of rationale follows: === mounting stacked ecryptfs on ecryptfs has been shown to lead to bugs in testing. For crypto info in xattr, there is no mechanism for handling this at all, and for normal file headers, we run into other trouble: BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: [] ecryptfs_d_revalidate+0x43/0xa0 [ecryptfs] ... There doesn't seem to be any good usecase for this, so I'd suggest just disallowing the configuration. Based on a patch originally, I believe, from Mike Halcrow. === This is a backport of commit 4403158ba295c8e36f6736b1bb12d0f7e1923dac https://bugs.launchpad.net/ubuntu/+bug/932987 Signed-off-by: Al Viro Signed-off-by: Colin Ian King --- fs/ecryptfs/main.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/fs/ecryptfs/main.c b/fs/ecryptfs/main.c index f6cd392..e2f18ad 100644 --- a/fs/ecryptfs/main.c +++ b/fs/ecryptfs/main.c @@ -496,6 +496,7 @@ out: } struct kmem_cache *ecryptfs_sb_info_cache; +static struct file_system_type ecryptfs_fs_type; /** * ecryptfs_fill_super @@ -571,6 +572,13 @@ static int ecryptfs_read_super(struct super_block *sb, const char *dev_name, ecryptfs_printk(KERN_WARNING, "path_lookup() failed\n"); goto out; } + if (path.dentry->d_sb->s_type == &ecryptfs_fs_type) { + rc = -EINVAL; + printk(KERN_ERR "Mount on filesystem of type " + "eCryptfs explicitly disallowed due to " + "known incompatibilities\n"); + goto out_free; + } if (check_ruid && path.dentry->d_inode->i_uid != current_uid()) { rc = -EPERM;