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
| ||
|
Date: Fri, 1 Jul 2011 23:00:11 +0200 From: Ingo Molnar <mingo@...e.hu> To: Will Drewry <wad@...omium.org> Cc: James Morris <jmorris@...ei.org>, Chris Evans <scarybeasts@...il.com>, linux-kernel@...r.kernel.org, Linus Torvalds <torvalds@...ux-foundation.org>, djm@...drot.org, segoon@...nwall.com, kees.cook@...onical.com, rostedt@...dmis.org, fweisbec@...il.com, tglx@...utronix.de, Randy Dunlap <rdunlap@...otime.net>, linux-doc@...r.kernel.org, Eric Paris <eparis@...hat.com>, linux-security-module@...r.kernel.org Subject: Re: [PATCH v9 05/13] seccomp_filter: Document what seccomp_filter is and how it works. * Will Drewry <wad@...omium.org> wrote: > On Fri, Jul 1, 2011 at 11:10 AM, Ingo Molnar <mingo@...e.hu> wrote: > > > But that's exactly my point: i consider it the right way forward > > because it maximizes kernel utility in the long run. > > Not if it never happens. Which is what happened with the proposals > from Adam and from Eric. Well, that's what my job is as a maintainer: to tell you if i dislike a solution and to suggest better solutions - and here this was really easy to do, as you already prototyped a solution i consider (far) superior. I cannot force you to do it like that, but i do have to say 'no'. > > are not some bad side effect or quirk, they are all generic > > improvements we want in any case and not just for sandboxing. > > I didn't say they were bad side effects or quirks. That's a pretty important point as well. > > You might not be interested in all of those items, you are only > > interested in getting the narrow feature-set you are interested > > in, but you sure are interested in getting sandboxing versus not > > getting anything at all, right? > > Unfortunately, that isn't the value proposition for me or many > other contributors. The real question is whether I am interested > in getting sandboxing in with mainline or if I want to sign up to > maintain the patches out of tree until my hair falls out. Well, if you implement the right solution then why should it stay out of tree? If the code is clean and useful and resolves all the technical objections that were raised against it then i will certainly merge it - and i hope Linus will chime in if he finds the actual iteration unacceptable and the direction harmful, to save us all the trouble. In the end the 'sandboxing' feature should be a few dozen lines at most - all the rest will just be shared infrastructure. Thanks, Ingo -- 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