From owner-freebsd-current Tue Oct 3 13:11:04 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA19461 for current-outgoing; Tue, 3 Oct 1995 13:11:04 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA19452 for ; Tue, 3 Oct 1995 13:11:00 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA01892; Tue, 3 Oct 1995 13:09:12 -0700 From: Terry Lambert Message-Id: <199510032009.NAA01892@phaeton.artisoft.com> Subject: Re: Another NFS server problem To: bde@zeta.org.au (Bruce Evans) Date: Tue, 3 Oct 1995 13:09:12 -0700 (MST) Cc: bde@zeta.org.au, terry@lambert.org, current@freebsd.org In-Reply-To: <199510031917.FAA27887@godzilla.zeta.org.au> from "Bruce Evans" at Oct 4, 95 05:17:47 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 721 Sender: owner-current@freebsd.org Precedence: bulk > > >> >The failure mode is triggered for a mkdir of an existing dir by a client, > >> >leaving the path name buffer allocated on the server. > >> > >> nfssrv_mkdir doesn't seem to be reached in that case. > > >Try it from a PC. > > What would a PC client do differently from a FreeBSD (nfsv3) client? calling the mkdir without doing a lookup and expecting the failure to be blocked at the server. I *should* be blocked at the server in any case, since otherwise, it's possible to hack ing (tho a "make directory" attack isn't like to make a CERT advisory any time soon 8-)). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.