linux-kernel - Re: [patch 01/15] security: pass path to inode

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:	Mon, 02 Jun 2008 11:52:52 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	hch@...radead.org
CC:	miklos@...redi.hu, hch@...radead.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, jmorris@...ei.org,
	sds@...ho.nsa.gov, eparis@...hat.com, casey@...aufler-ca.com,
	agruen@...e.de, jjohansen@...e.de,
	penguin-kernel@...ove.SAKURA.ne.jp, viro@...IV.linux.org.uk,
	linux-kernel@...r.kernel.org
Subject: Re: [patch 01/15] security: pass path to inode_create

> > You act like a happy prince of VFS, but let me tell you one thing,
> > there's only one king in this kingdom of Linux, and that's Linus
> > Torvalds I.  And our wise king already said that apparmor can come, so
> > the question is not "if" but "how".
> > 
> > If you don't want to help, that's a pity, but of course I don't want
> > to (and can't) force you.  I can understand if personally you don't
> > think this is a good idea, and don't want to have anything to do with
> > it.  In that case I can leave you off the CC's for the parts which are
> > not just generic VFS cleanups but explicitly towards apparmor
> > integration.  Would that suit you?
> 
> No, 

So shall I leave you _on_ the CC's then?

> and Agenda doesn't make these patches any better.

Umm, what's wrong with the patches then?  What exactly do they break?
How do they make the kernel bigger and slower?  How do they make the
code less readable?

These patches fix several issues raised at previous submissions:

 - passing NULL vfsmounts
 - using nameidata
 - using extra stack for vfsmount argument

So, it seems to me that there's in fact no issues remaining and the
best excuse you can come up with is that it's a dumb idea.  Well,
that's not a very imressive technical argument IMNSHO.

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/