From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754622AbdBQC3g (ORCPT ); Thu, 16 Feb 2017 21:29:36 -0500 Received: from zeniv.linux.org.uk ([195.92.253.2]:34550 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753420AbdBQC3e (ORCPT ); Thu, 16 Feb 2017 21:29:34 -0500 Date: Fri, 17 Feb 2017 02:29:18 +0000 From: Al Viro To: James Bottomley Cc: Djalal Harouni , Chris Mason , Theodore Tso , Josh Triplett , "Eric W. Biederman" , Andy Lutomirski , Seth Forshee , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, Dongsu Park , David Herrmann , Miklos Szeredi , Alban Crequy , "Serge E. Hallyn" , Phil Estes Subject: Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount Message-ID: <20170217022918.GC29622@ZenIV.linux.org.uk> References: <1486235880.2484.17.camel@HansenPartnership.com> <1486235972.2484.19.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1486235972.2484.19.camel@HansenPartnership.com> User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Feb 04, 2017 at 11:19:32AM -0800, James Bottomley wrote: > +static const struct dentry_operations shiftfs_dentry_ops = { > + .d_release = shiftfs_d_release, > + .d_real = shiftfs_d_real, > +}; In other words, those dentries are *never* revalidated. Nevermind that underlying fs might be mounted elsewhere and be actively modified under you. > +static struct dentry *shiftfs_lookup(struct inode *dir, struct dentry *dentry, > + unsigned int flags) > +{ > + struct dentry *real = dir->i_private, *new; > + struct inode *reali = real->d_inode, *newi; > + const struct cred *oldcred, *newcred; > + > + inode_lock(reali); > + oldcred = shiftfs_new_creds(&newcred, dentry->d_sb); > + new = lookup_one_len(dentry->d_name.name, real, dentry->d_name.len); > + shiftfs_old_creds(oldcred, &newcred); > + inode_unlock(reali); > + > + if (IS_ERR(new)) > + return new; > + > + dentry->d_fsdata = new; > + > + if (!new->d_inode) > + return NULL; What happens when somebody comes along and creates the damn thing on the underlying fs? _Not_ via your code, that is - using the underlying fs mounted elsewhere.