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 19:52:35 +0100
From:	Miklos Szeredi <miklos@...redi.hu>
To:	viro@...IV.linux.org.uk
CC:	miklos@...redi.hu, haveblue@...ibm.com,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	neilb@...e.de, akpm@...ux-foundation.org, hch@...radead.org,
	linux-security-module@...r.kernel.org, jmorris@...ei.org
Subject: Re: r-o bind in nfsd

> > > 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.
> 
> I really don't see the point of new helpers; especially since one doesn't
> have to _have_ vfsmount to use the old ones and since we don't have a lot
> of users of each of those to start with.

Traditionally we have syscalls, and nfsd.  Both of them want the
security checks, and I think nfsd wants the read-only mount checking
as well, but I'm not entirely sure.  Maybe we can handle that by just
making nfsd acquire a write-ref on the mount and keep it while it's
exported.

Then there's ecryptfs and unionfs, which probably need neither, but it
wouldn't hurt to do them anyway.

Still, even if there are only two callers, then moving stuff to up
doesn't make any sense.  Passing down a struct path is free for the
syscall case, it doesn't consume any stack space or extra CPU.  Do
please tell, why would that be such a bad thing?

Miklos
--
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/