To: viro@ZenIV.linux.org.uk
CC: haveblue@us.ibm.com, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org, neilb@suse.de, akpm@linux-foundation.org,
       hch@infradead.org, linux-security-module@vger.kernel.org,
       jmorris@namei.org
In-reply-to: <E1JckW9-0001Ub-Rs@pomaz-ex.szeredi.hu> (message from Miklos
	Szeredi on Fri, 21 Mar 2008 17:54:57 +0100)
Subject: Re: r-o bind in nfsd
References: <E1Jciie-0001E6-Dx@pomaz-ex.szeredi.hu> <20080321155451.GU10722@ZenIV.linux.org.uk> <E1Jck2N-0001Q3-7W@pomaz-ex.szeredi.hu> <20080321163520.GV10722@ZenIV.linux.org.uk> <E1JckW9-0001Ub-Rs@pomaz-ex.szeredi.hu>
Message-Id: <E1Jckjd-0001X8-IM@pomaz-ex.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Fri, 21 Mar 2008 18:08:53 +0100
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1117
Lines: 25

> Nobody wants to send vfsmounts to the filesystem.  But vfs_...() are
> still part of the "upper layer", not the filesystem, so I'm not
> convinced yet.  For example:
> 
> -extern int vfs_mkdir(struct inode *, struct dentry *, int);
> +extern int vfs_mkdir(const struct path *, struct dentry *, int);
> 
> There's one caller of vfs_mkdir that can't do this: cgroup_clone().
> But that can call cgroup_mkdir() instead.
> 
> And having the vfsmount available within vfs_...() functions means,
> that the mnt_want_write() check can be moved inside, which means that
> callers get simpler and less likely to be buggy.  Those are all
> advantages IMO, regardless of any security module issues.

Or we can introduce another set of exported functions (path_mkdir(),
...), and leave vfs_...() alone.  And then the only question is if
LSM's can live with ordering change.

Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/