From owner-freebsd-hackers  Wed Oct 25 06:28:15 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id GAA13791
          for hackers-outgoing; Wed, 25 Oct 1995 06:28:15 -0700
Received: from time.cdrom.com (time.cdrom.com [192.216.222.226])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA13764
          ; Wed, 25 Oct 1995 06:28:10 -0700
Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id GAA27344; Wed, 25 Oct 1995 06:27:34 -0700
To: davidg@Root.COM
cc: mikebo@tellabs.com, hackers@freebsd.org, bugs@freebsd.org
Subject: Re: 2.1.0-951020-SNAP: Major bug in NFS again! 
In-reply-to: Your message of "Tue, 24 Oct 1995 20:38:46 PDT."
             <199510250338.UAA27854@corbin.Root.COM> 
Date: Wed, 25 Oct 1995 06:27:33 -0700
Message-ID: <27341.814627653@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-hackers@freebsd.org
Precedence: bulk

>    This is obviously flamebait and I'm not going to respond to it.

I don't think he meant it as flamebait, I read it as him simply trying
to state a position (which he did at least mark with a "soapbox on",
thus indicating that he knew it to be a contraversal issue) that if
FreeBSD can't interoperate with the big boys, then people aren't going
to praise FreeBSD for taking the high road, they're going to say that
FreeBSD is crap because it can't even talk to the most popular
workstation platform on the planet.  I can at least see where he's
coming from!

> bypass the system security. Other commercial vendors are running old security
> broken versions of NFS and this makes them wide open for security attacks.

And I can see your point as well.  Clearly, it's Sun that needs to
clean their house and not us..  They've screwed the pooch and I hope
Mike can at least understand the natural horror reaction at proposing
we lobotomize our security just to cope with someone else's total lack
of it.  Maybe we can reach a compromise..

>    The best I could offer you would be a kernel option to disable this
> security, but I'll say right now that this *won't* be in the 2.1 release.

I agree - 2.1 is simply too close, though I see no reason why the
power-users won't be able to retrofit your solution from 2.2.  Still,
this strikes me as a problem we're going to see reported often enough
that maybe we should make it a MIB variable instead of a kernel
compile option, ala the net.inet.tcp.rfc* knobs we already support.

					Jordan