linux-kernel - Re: [patch 00/13] vfs: add helpers to check r/o bind mounts

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]

Message-ID: <20080424124245.GC15214@ZenIV.linux.org.uk>
Date:	Thu, 24 Apr 2008 13:42:46 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	akpm@...ux-foundation.org, torvalds@...ux-foundation.org,
	dave@...ux.vnet.ibm.com, ezk@...sunysb.edu, mhalcrow@...ibm.com,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [patch 00/13] vfs: add helpers to check r/o bind mounts

On Thu, Apr 24, 2008 at 01:39:50PM +0200, Miklos Szeredi wrote:
> Then I did this series, which basically guarantees, that that cannot
> happen.  Al rejected it, and rather fixed some of the remaining
> places.  He still missed several, which sort of proves my point.

Which ones have I missed?

> I think it's totally pointless to continue trying to fix the symptoms
> instead of getting at the root of the problem.
> 
> I know that VFS interfaces are a sensitive question, but it would be
> nice it we could have some sanity back in this discussion.

Yes, it would.  How about that, for starters:

path_create() et.al. are *wrong* for nfsd; if nothing else, I'm not at
all convinced that even apparmour wants export path + relative there
_and_ r/o vs. r/w is decision that doesn't clearly map to ex_mnt flags.

Moreover, it's not at all obvious that we want to drop write access as
soon as vfs_...() is over in case of nfsd.  Some of the stuff done
immeidately afterwards might very well qualify for inclusion into
protected area; some of the stuff done immediately _prior_ very likely
needs that as well - look at fh_verify() and tell me why we don't want
that "I'll hold write access to vfsmount" to span the area including
that sucker.  If we want the r/o vs r/w policy directly vfsmount-based
for nfsd, that is.

For ecryptfs it's also bogus - at the very least we need to decide what
should happen when underlying vfsmount is remounted.  Again, I'm less
than convinced that we want the same way to express r/o vs. r/w policy.
--
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/