linux-kernel - Re: r-o bind in nfsd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 21 Mar 2008 16:35:20 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	haveblue@...ibm.com, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, neilb@...e.de,
	akpm@...ux-foundation.org, hch@...radead.org
Subject: Re: r-o bind in nfsd

On Fri, Mar 21, 2008 at 05:24:11PM +0100, Miklos Szeredi wrote:
> > > I know there are a few cases, where filesystems call vfs_foo()
> > > internally, where the vfsmount isn't available, but I think the proper
> > > solution is just to fix those places, and not recurse back into the
> > > VFS (which is AFAICS in all those cases totally unnecessary anyway).
> > > This would make everybody happy, no?
> > 
> > Apparmor can go play with itself.  The proper fix is to lift the LSM nonsense
> > into callers and leave vfs_...() alone;
> 
> Maybe.  I know precious little about this security thing, so I won't
> argue about it's merits or faults.  But:
> 
>  a) I have a hunch that the security guys wouldn't like to see the
>  order between permission() and security_foo() changed.

It's their problem.  Adjusting LSM methods, if needed, is up to LSM
maintainers, whenever moving the hooks or code around those become
convenient for kernel proper.  According to Linus, IIRC.

Especially since in this case they want to change prototypes anyway, so the
churn is not an issue and having the hook called earlier is very unlikely to
cause any problems.

>  b) I fail to see how moving functionality to callers would improve
>  things
> 
> > vfsmounts should *not* be passed there at all, with the exception of
> > vfs_follow_link() which gets the full nameidata.
> 
> Why?

Because filesystem shouldn't _care_ where it is mounted.  Anything
vfsmount-dependent belongs to upper layers.  The same goes for passing
nameidata to fs methods, BTW - again, ->follow_link() is an obvious
legitimate exception.
--
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/