Date: Thu, 5 Apr 2001 00:38:11 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: rwatson@FreeBSD.ORG (Robert Watson) Cc: freebsd-arch@FreeBSD.ORG, dillon@FreeBSD.ORG Subject: Re: Eliminate crget() from nfs kernel code? Message-ID: <200104050038.RAA03316@usr08.primenet.com> In-Reply-To: <Pine.NEB.3.96L.1010403164943.7478F-100000@fledge.watson.org> from "Robert Watson" at Apr 03, 2001 05:00:11 PM
next in thread | previous in thread | raw e-mail | index | archive | help
[ ... 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104050038.RAA03316>