On Fri, 13 Jul 2001, Greg KH wrote: > On Fri, Jul 13, 2001 at 04:59:59PM -0400, jmjonesat_private wrote: > A complete statement of opinion. > > How I have come to have that opinion: > Both of those reasons are reasons patches have been rejected from > the kernel in the past. My own included. Both of these reasons are > public knowledge if you read the kernel mailing lists and talk to > the developers themselves. > > Hell, I've rejected patches from people for those very reasons for > the small portion of the kernel that I am a maintainer for :) > > So my opinion is based on personal experience and public knowledge, > which can be researched. > > And you base your opinion on? :) Okay, if you want to go there... My opinion is based on 20+ years of experience designing, contracting, and implementing software solutions for Linux, Windows, MSDOS, Unix, VMS, OpenVMS, and other not-so-widely-known operating systems. How many years have you been doing this? The *key* to getting ANY API accepted is to contrive it so coders look at it and say "hey, brilliant, that gives me an idea...". All Kernel Developers are coders, first. Selling an API that provides something USEFUL, and answers the "hrm, perhaps it's incomplete? what about..." question is easier than selling one that's USEFUL and incomplete... to coders. Are you saying that the majority of Kernel Developers are too naive to see the issues we've raised but decided not to address ? Yes. I agree: I've rejected code that has a lot of wasted bytes to preserve opportunities *THAT WERE NOT IMPORTANT*, but there have been a LOT of permissive opinions here and they've been largely "rejected out of hand" in the "consensus" equation. Maybe 60/40 restrictive/permissive. Changing the naming convention and structure definition to address the 40% costs about 30 minutes effort, and a consensus to do so. What are the arguments AGAINST it, other than your "experience?" > > > My proposal doesn't prevent this. It simply changes the security_ops > > structure minimally to address other needs. > > If it isn't needed today, don't have code that has it in it today. > That's one of the kernel source rules. My point is it IS needed. Not to everybody, but to many, many people. Numerous posters to this list have argued for it. What ISN'T needed, in Stage I, is to address it with hooks, but what *IS* needed is an acknowlegment of its relevance for being encompassed in LSM, at least in a "future plans" sense. > > Unless we are talking about reserved fields in data structures that _can > not change_ over time. Like those in a filesystem, or those that > interact with userspace. Our data structures are neither. Hence, we > can change them over time as modules come to need them, _after_ we get > the current stuff finished and accepted. security_ops->permissive_ops need not change from NULL in the future, nor need any of the hooks admitted in Stage II-X change, if implemented within my proposal. Are you saying security_ops->inode_ops->something will NEVER EVER CHANGE in the future? Oh, and generally... I've been with Linux since 1.x... EVERYTHING can be changed over time. That's a prime argument used AGAINST a lot of things on this list: nothing is carved in stone. > > greg k-h > Due Respect, J. Melvin Jones |>------------------------------------------------------ || J. MELVIN JONES jmjonesat_private |>------------------------------------------------------ || Microcomputer Systems Consultant || Software Developer || Web Site Design, Hosting, and Administration || Network and Systems Administration |>------------------------------------------------------ || http://www.jmjones.com/ |>------------------------------------------------------ _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Fri Jul 13 2001 - 14:57:34 PDT