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:	Wed, 2 Apr 2008 21:54:50 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	akpm@...ux-foundation.org, dave@...ux.vnet.ibm.com,
	ezk@...sunysb.edu, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [patch 01/10] vfs: add path_create() and path_mknod()

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*.  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-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

Powered by Openwall GNU/*/Linux Powered by OpenVZ