From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: Adding a security parameter to VFS functions Date: Fri, 17 Aug 2007 00:34:12 +0100 Message-ID: <20070816233412.GO21089@ftp.linux.org.uk> References: <29015.1187178055@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: David Howells , sds@tycho.nsa.gov, casey@schaufler-ca.com, linux-fsdevel@vger.kernel.org, nfsv4@linux-nfs.org, linux-kernel@vger.kernel.org, selinux@tycho.nsa.gov, linux-security-module@vger.kernel.org To: Linus Torvalds Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-security-module-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, Aug 16, 2007 at 03:57:24PM -0700, Linus Torvalds wrote: > I personally consider this an affront to everythign that is decent. > > Why the *hell* would mkdir() be so magical as to need something like that? > > Make it something sane, like a "struct nameidata" instead, and make it at > least try to look like the path creation that is done by "open()". Or > create a "struct file *" or something. No. I agree that mkdir/mknod/etc. should all take the same thing. *However*, it should not be nameidata or file. Why? Because it should not contain vfsmount. Object creation should not *care* where fs is mounted. At all. The same goes for open(), BTW - letting it see the reference to vfsmount via nameidata is bloody wrong and I really couldn't care less what kinds of perversions apparmour crowd might like - pathnames simply do not belong there. Said that, I agree that we need uniform prototypes for all these guys and I can see arguments both for and against having creds passed by reference stored in whatever struct we are passing (for: copy-on-write refcounted cred objects would almost never have to be modified or copied and normally we would just pick the current creds reference from task_struct and assing it to a single field in whatever we pass instead of nameidata; against: might be conceptually simpler to have all that data directly in that struct and a helper filling it in). Which way we do that and which struct we end up passing is a very good question, but I want to make it very clear: having object creation/removal/ renaming methods[1] depend on which vfsmount we are dealing with is *wrong*. IOW, I strongly object against the use of nameidata here.