[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1207226011.27710.142.camel@moss-spartans.epoch.ncsc.mil>
Date: Thu, 03 Apr 2008 08:33:31 -0400
From: Stephen Smalley <sds@...ho.nsa.gov>
To: Al Viro <viro@...IV.linux.org.uk>
Cc: Miklos Szeredi <miklos@...redi.hu>, akpm@...ux-foundation.org,
dave@...ux.vnet.ibm.com, ezk@...sunysb.edu,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org,
Chris Wright <chrisw@...s-sol.org>,
James Morris <jmorris@...ei.org>,
Eric Paris <eparis@...isplace.org>
Subject: Re: [patch 01/10] vfs: add path_create() and path_mknod()
On Wed, 2008-04-02 at 21:54 +0100, Al Viro wrote:
> On Wed, Apr 02, 2008 at 10:12:48PM +0200, Miklos Szeredi wrote:
> > From: Miklos Szeredi <mszeredi@...e.cz>
> >
> > R/o bind mounts require operations which modify the filesystem to be
> > wrapped in mnt_want_write()/mnt_drop_write(). Create helpers which do
> > this, so callers won't need to bother, and more importantly, cannot
> > forget! Call these path_*, analogous to vfs_*. Where there are no
> > callers of vfs_* left, make them static.
> >
> > This series is a cleanup, as well as fixing several places (mostly in
> > nfsd) where mnt_{want,drop}_write() were missing.
> >
> > It will also help with merging You Know What(*) security module, which
> > needs to know the path within the namespace, and not just within the
> > filesystem. These helpers will allow the security hooks to be in a
> > common place, and need not be repeated in all callers.
>
> Rot.
>
> Places in nfsd must be fixed, LSM hooks *moved* *to* *callers*.
Please don't move the existing security_inode hooks - they are at
exactly the right location for SELinux and likely other security modules
too - after the DAC checks (so no noise in the audit logs from accesses
that would be denied by DAC anyway), and right before the inode method
is invoked (so easy to see that the permission check is always invoked
before access). Moving the existing hooks will break the first property
unless the DAC checks are also moved and will make it harder to check
and maintain the second property.
> And
> really, by that point I absolutely do not give a damn for these clowns.
> "Help with merging" implies that they can't be arsed to do _anything_
> with their code. Just as they could not be arsed to react to any
> comments (including civil ones) in any manner except "wait for a month
> and repost without changes". Sod them.
>
> And no, "make static where all (two of) current callers have vfsmount"
> is non-starter. path_...() is (at most) a convenience helper, not a
> fundamental interface - simply because new callers should not be
> forced into inventing a fake vfsmount just to use that.
>
> I'll look into missing mnt_..._write() in nfsd and fix that. The rest...
> Sorry.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Stephen Smalley
National Security Agency
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists