From: Andrew Morton
Date: Mon May 10 2004 - 18:53:05 EST
Chris Wedgwood <cw@xxxxxxxx> 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
> > 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
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/