Message ID | 20160322132302.GE11906@tucsk (mailing list archive) |
---|---|
State | New, archived |
Headers | show
Return-Path: <linux-fsdevel-owner@kernel.org> X-Original-To: patchwork-linux-fsdevel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 3324DC0553 for <patchwork-linux-fsdevel@patchwork.kernel.org>; Tue, 22 Mar 2016 13:21:51 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 5C446201EF for <patchwork-linux-fsdevel@patchwork.kernel.org>; Tue, 22 Mar 2016 13:21:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5D1DB20155 for <patchwork-linux-fsdevel@patchwork.kernel.org>; Tue, 22 Mar 2016 13:21:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758789AbcCVNVq (ORCPT <rfc822;patchwork-linux-fsdevel@patchwork.kernel.org>); Tue, 22 Mar 2016 09:21:46 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:33269 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753679AbcCVNVo (ORCPT <rfc822;linux-fsdevel@vger.kernel.org>); Tue, 22 Mar 2016 09:21:44 -0400 Received: by mail-wm0-f66.google.com with SMTP id u125so3644306wmg.0 for <linux-fsdevel@vger.kernel.org>; Tue, 22 Mar 2016 06:21:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=V0L/myTvuMX76vzIFAN+mGGpgYl4cBv509UbD/GtN34=; b=j72vtVLUNn45sIEUHjtpyVphwgWiSDlMEWIjigkwgKK3MaEinFcEBBjxuInoRIHAQo x7R5qgqp5lCcjO74cu8pCEHRIgfAKeQI0L0Akc8oCWg9acLQ7HK2fCnzrYulHlti/Ibi CscIbnGSwRJCIdEENHX0tcyHWgnMDUjwBoDKI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=V0L/myTvuMX76vzIFAN+mGGpgYl4cBv509UbD/GtN34=; b=lUuRNDl3rnW1c+73A+odRTrFA5Vwf+cxjSvSC82h8q6FA60ojBSfzfQnvSkqAfDEK1 uL4If2/kGJ8VvGctV/6HUpO81sv2tPeAUaB6w4qXVfRoMVu38vlL2/qV3G2Sy4GQLNGx nMe1yzZkDKuFCyOQFUSmncQ/YhP/O5AuazkhuYS5vtU1XUgU+KlMUi/dyW4JSoWsxWpP YtKPpZmZhHDBGtK8Q6lV18KEpyz0BLPi/uMOdz4OJHbqCv2EBYDC3+Ina5Y0aXt1poXX t+0tiM6zktxjj6DPtH6j5uDNaW+diCJsCZehwNN2KODAhNiHNq55/ZDZaXKQMTMSTS7s Tvlw== X-Gm-Message-State: AD7BkJJAD+gM1mXCPLwB6krWw4TEo+88MRi2a32GygluiiZRvLLuGNBTKcXLTAVquGNbjg== X-Received: by 10.194.63.7 with SMTP id c7mr36617788wjs.168.1458652903175; Tue, 22 Mar 2016 06:21:43 -0700 (PDT) Received: from tucsk (pool-dsl-2c-0018.externet.hu. [217.173.44.24]) by smtp.gmail.com with ESMTPSA id js8sm30165498wjc.37.2016.03.22.06.21.42 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 22 Mar 2016 06:21:42 -0700 (PDT) Date: Tue, 22 Mar 2016 14:23:02 +0100 From: Miklos Szeredi <miklos@szeredi.hu> To: Al Viro <viro@zeniv.linux.org.uk> Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-unionfs@vger.kernel.org Subject: [PATCH 2/2] ovl: ignore permissions on underlying lookup Message-ID: <20160322132302.GE11906@tucsk> References: <20160322132103.GD11906@tucsk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160322132103.GD11906@tucsk> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: <linux-fsdevel.vger.kernel.org> X-Mailing-List: linux-fsdevel@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID,T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP |
--- a/fs/overlayfs/super.c +++ b/fs/overlayfs/super.c @@ -379,7 +379,7 @@ static inline struct dentry *ovl_lookup_ struct dentry *dentry; inode_lock(dir->d_inode); - dentry = lookup_one_len(name->name, dir, name->len); + dentry = lookup_hash(name, dir, 0); inode_unlock(dir->d_inode); if (IS_ERR(dentry)) {
Generally permission checking is not necessary when overlayfs looks up a dentry on one of the underlying layers, since search permission on base directory was already checked in ovl_permission(). More specifically using lookup_one_len() causes a problem when the lower directory lacks search permission for a specific user while the upper directory does have search permission. Since lookups are cached, this causes inconsistency in behavior: success depends on who did the first lookup. So instead use lookup_hash() which doesn't do the permission check. Reported-by: Ignacy Gaw?dzki <ignacy.gawedzki@green-communications.fr> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com> --- fs/overlayfs/super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html