lkml.org 
[lkml]   [2003]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: What went wrong with LSM, was: Re: [BK PATCH] LSM changes for 2.5.59
James Morris wrote:

>On Wed, 12 Feb 2003, 'Christoph Hellwig' wrote:
>
>>And here we see _the_ problem with the LSM process. LSM wasn't
>>developed as part of the broad kernel community (lkml) but on
>>a rather small, almost private list.
>>
>>
>Many of the things that you are saying in this discussion are untrue.
>
>The bulk of the development process was carried out for more than two
>years on the LSM development mailing list, which is fully public and open
>to anyone. It is not "almost private", whatever that is supposed to mean.
>
For the record:

* The LSM code patches have always been publicly available for
anonymous checkout via BK from http://lsm.immunix.org/
* The LSM mailing list is managed by Mailman and is open for anyone
to subscribe
<http://mail.wirex.com/mailman/listinfo/linux-security-module>,
unsubscribe, or view the archives
<http://mail.wirex.com/pipermail/linux-security-module/>.
* The LSM mailing list is also independently archived elsewhere
<http://marc.theaimsgroup.com/?l=linux-security-module&r=1&w=2>.
* For the first year or so, the LSM mailing list was "closed" in
that posts from non-subscribers were trapped for moderation. I
always approved such posts if they were topical, and used the
moderation only to filter spam.
* Subsequent to that, I was told that this is "not the linux way"
and the mailing list was made "open" so that anyone can post, and
Spamassassin was installed to filter spam (which doesn't quite
work perfectly
<http://mail.wirex.com/pipermail/linux-security-module/2002-October:/3658.html>).

It has never, ever been "private" any more than any of the other
subsystem -devel lists are "private."

>As for "rather small", hundreds of people were involved in discussion
>during the initial development phase (Chris Wright generated some stats on
>this last year).
>
A few days after I opened the list, it had 300 subscribers. Today it has
607 subscribers. There have been 4183 posts.

>There were specific LSM discussions at two kernel summits, while multiple
>OLS presentations have been given on LSM.
>
To me, the most gratifying result to come out of OLS 2002
<http://www.linuxsymposium.org/2002/> (apart from Linus accepting the
first patch :-) was the Ericsson project
<http://www.linuxsymposium.org/2002/view_txt.php?text=abstract&talk=44>.
What makes this project so impressive is that AFAIK Ericsson never asked
the LSM mailing list a single question. They just took the documents and
the code, and implemented their module. To me, *that* is evidence that
the abstraction is usable: that an independent 3rd party can code to it
without help.

>I do agree that we should have worked more closely with maintainers from
>the beginning, but this was not out of trying to be secretive (of which we
>have been accused quite a few times). This happened out of believing that
>we should reach a design consensus and write some code via the before
>bothering any maintainers. This approach was clearly flawed, and efforts
>have since been made to rectify this for ongoing development.
>
And in fact we did seek input from Theodore Ts'o in the summer of 2001.
Most of that guidance was verbal, and it happened 18 months ago, so my
memory is imperfect, but I think he advised us to keep the invasiveness
minimal, and to avoid adding features that were just there to support
audit. Others at that lunch were Chris Wright (WireX) and Pete Loscocco
(SELinux).

What I've learned from the LSM merge process is that we need to get
piecewise buy-in from each major subsystem maintainer that will be
impacted. For instance, the network hooks did not go in as smoothly as
we would have liked. Thanks to hard work from James Morris and helpful
feedback from David Miller, they did go in after substantial revisions.
Next time, we will float a paper design past subsystem maintainers ahead
of time.

>Claims of a "secret" and non-generalized design process are baseless.
>
Here here.

Crispin

--
Crispin Cowan, Ph.D.
Chief Scientist, WireX http://wirex.com/~crispin/
Recruiting for Linux kernel and glibc developers: http://immunix.org/jobs.html

[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-03-22 13:33    [from the cache]
©2003-2011 Jasper Spaans