From owner-freebsd-arch Wed Apr 4 17:38:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp10.phx.gblx.net (smtp10.phx.gblx.net [206.165.6.140]) by hub.freebsd.org (Postfix) with ESMTP id 34B6F37B423; Wed, 4 Apr 2001 17:38:15 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp10.phx.gblx.net (8.9.3/8.9.3) id RAA24936; Wed, 4 Apr 2001 17:38:14 -0700 Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp10.phx.gblx.net, id smtpdJ7Am7a; Wed Apr 4 17:38:13 2001 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id RAA03316; Wed, 4 Apr 2001 17:38:12 -0700 (MST) From: Terry Lambert Message-Id: <200104050038.RAA03316@usr08.primenet.com> Subject: Re: Eliminate crget() from nfs kernel code? To: rwatson@FreeBSD.ORG (Robert Watson) Date: Thu, 5 Apr 2001 00:38:11 +0000 (GMT) Cc: freebsd-arch@FreeBSD.ORG, dillon@FreeBSD.ORG In-Reply-To: from "Robert Watson" at Apr 03, 2001 05:00:11 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ ... crget() ... ] I am not too happy with crget() at the moment. Even discounting the fact that it calls MALLOC(), and does not check the results (the new [BAD] semantics permit this to fail under extremely low memory conditions [FOR NO GOOD REASON] instead of hanging), it is not the only place this happens in FreeBSD, so just because it's a panic waiting to happen is no real excuse to kill it, since it is in good company (e.g. crdup()). I also have a network load related panic that claims to panic in crdup() as a result of it calling crget() and getting bad data (yes, this is 4.3, and crdup() has been fixed in -current to get it's own bad data, instead of relying on crget() for it). If you "fix" crget(), you will also need to fix crdup(). There are plenty of places where crdup() is called, not just in the access() system call, where it is bogusly used to replace _only_ the initial group of the real GID, leaving the groups of the effective UID active, falsely yielding access to the file, even if the real UID would have not have contained the same group list as the effecive UID (gotta love "security" code). My recommendation is to fix the bogosities, like the non-check of the MALLOC() return, and to leave it the heck alone in the NFS case. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message