linux-kernel - Re: [patch 01/10] vfs: add path_create() and path

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] [day] [month] [year] [list]

Date:	Tue, 06 May 2008 08:24:48 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	viro@...IV.linux.org.uk
CC:	akpm@...ux-foundation.org, miklos@...redi.hu, hch@...radead.org,
	dave@...ux.vnet.ibm.com, ezk@...sunysb.edu, mhalcrow@...ibm.com,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	haveblue@...ibm.com
Subject: Re: [patch 01/10] vfs: add path_create() and path_mknod()

> > > 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_*.  Since there are no
> > > callers of vfs_* left, make them static.
> > 
> > ooh, yum.  This appears to address my main complaint about the
> > r-o-bind-mount stuff: fragility.
> > 
> > > Overall this patchset is just 23 lines in the red, but at the same
> > > time it fixes several places in nfsd and the whole of ecryptfs, where
> > > the mnt_want_write/drop_write() calls were missing.
> > 
> > Yeah, like that.
> 
> Except that it fixes nothing in nfsd, as we'd already figured out

Oh, it does!  It fixes at least one race, where nfsd is checking for
r/o mounts but is not keeping the mount from being marked r/o during
the operation.

I also suspect it fixes more than that, that we all just missed when
going over the callers of vfs_*().

> and
> "solution" for ecryptfs is more than slightly dubious.  Not that nfsd
> one wasn't...
> 
> While we are at it, I call bullshit on "make vfs_...() static" and I suspect
> that Miklos won't be happy with it once he cares to think through just how
> little is going to be guaranteed about those vfsmounts.  As in "not promised
> to be attached anywhere", for starters...

How does attachment figure into being marked r/o?  Or into anyting
else, for that matter: no path looked up is ever guaranteed to be
attached, and we've been getting along fine with that.

Al, I've thought this over very well, and it seems to me that you've
just been trying to find excuses.  Which is OK, I guess: that's what
review is about.  But at some point we shouold really just move on.

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/