Re: 2.6.6-mm1

Chris Wedgwood <cw@f00f.org> wrote:
>
> On Mon, May 10, 2004 at 04:28:18PM -0700, Andrew Morton wrote:
> 
> > If vendors are forced to ship a nasty hack it often points at
> > problems in the mainline kernel.  Certainly that's true in this
> > case.
> 
> Yes, so let's discuss it and think about a nice clean solution rather
> than hastily merge something that 'seems to work' without considering
> the long term consequences of this.

Has been discussed on this list.  It requires worrisome changes to the
capability system, changes to PAM, changes to login and changes to
applications.

> > And if we are unable to fix the kernel acceptably then I'd prefer
> > that the expedient fix be in the mainstream kernel so as to prevent
> > divergence in user-visible features between vendor kernels.
> 
> And when we have a clean solution we will have to live with this hack
> too.

Maybe that's the price we pay for leaving this problem unsolved for a year.
I must say that it's also to some extent a consequence of ISV's and
vendors quitely working on problems in little corners.

> > And let's remember, code-wise, this is a very small change.
> 
> It's not the code size --- it's the fact we add a strange new semantic
> (magic group) without what IMO is sufficient thought and discussion
> into a stable kernel series knowing that we will probably *NEVER* be
> able to remove this wart once we have a better solution.

There is no magic group unless the admin chooses to set the sysctl.

> > But it's too late.
> 
> Why?  Also, most existing users will be 2.4.x --- why does that not
> nee this but 2.6.x _MUST_ had it?
> 
> > This stuff is going out the door to end 2.6 users and that's just
> > tough luck.  The least we can do is to ensure that it works the same
> > across different vendor's kernels.
> 
> When was this issue properly discussed?  It seems like it's a new
> issue that's be hurried out the door without much consultation.
> 
> It might be my interpretation, but this also reads to me like "I don't
> think it's too ugly, it's my party so tough shit if you don't like it"
> :)

You misunderstand.  Nasty workarounds will be shipped to end users by
vendors.  That's a certainty.  We cannot change this now.

What I wish to do is to ensure that all users receive the *same* nasty
workaround.  Call it damage control.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/