linux-kernel - Re: [PATCH] utimensat() non-conformances and fixes [v3]

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, 30 May 2008 22:08:20 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	matthew@....cx
CC:	miklos@...redi.hu, mtk.manpages@...glemail.com, drepper@...hat.com,
	viro@...iv.linux.org.uk, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, linux-man@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] utimensat() non-conformances and fixes [v3]

> > For 2) you can just use permission() instead of vfs_permission() which
> > is exactly the same in this case (and consolidated into a common
> > function later in the vfs-cleanups tree).
> 
> Miklos, don't delude people into thinking the vfs-cleanups tree is ever
> going to get merged in its current state.  Al's NAKed the path_* stuff,
> Christoph's NAKed it too.

Actually, the cleanup patches which I'm asking Michael to base his
patches on were not NAKed.

And Michael is not even working against the vfs-cleanups tree, but
rather just a couple of these utimes cleanup patches, none of which
are controversial like the path_* stuff.  But even if he was working
against the vfs-cleanups tree it wouldn't matter, since porting
patches to/from the path_* API is trivial.

>  Ignoring them and putting up a VFS tree of your own is not going to
> help matters.

Do please tell me how else should I work?  I post patches for review,
gradually, not as a 100 patch series, when we manage to submit
apparmor.  That far easier for people to handle, and sure enough I get
comments are testing for this stuff.

As for Al's NAK: the only alternative suggestion he has been able to
come up is to move the security hooks into callers.  And that has been
NAKed (not surprisingly) by the selinux folks.  And there's nothing
actually _wrong_ with those patches, they don't add complexity
(actually they remove complexity), they don't slow down the kernel,
and they even fix some bugs.  Now what the hell more do we need?

Thanks,
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/