From owner-freebsd-current Mon Oct 2 15:55:21 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA29296 for current-outgoing; Mon, 2 Oct 1995 15:55:21 -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 PAA29291 for ; Mon, 2 Oct 1995 15:55:18 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA22715 for current@freebsd.org; Mon, 2 Oct 1995 15:49:41 -0700 From: Terry Lambert Message-Id: <199510022249.PAA22715@phaeton.artisoft.com> Subject: NFS server problems To: current@freebsd.org Date: Mon, 2 Oct 1995 15:49:40 -0700 (MST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1064 Sender: owner-current@freebsd.org Precedence: bulk I've discovered a problem in the VFS server code, specifically with the nfsrv_create() function in the NFSV3CREATE_GUARDED case. The error code is set to EEXIST, but since the nd.ni_vp is non-NULL, it falls through to the "truncate existing file" case instead of actually returning that error. The error code is actually overridden by an access check which (apparently) does not take "read only" into account and subsequently truncates the file to the requested size (if that is not -1). Instead one would expect it to return EEXIST, the error code set, and skip subsequent operations in the create routine. There are also some VOP_ABORTOP ordering issues that aren't critical if the NFS server is exporting a UFS dile system, but which might be an issue for a non-UFS file system. The abort operation should take place before namidata structure contents are touched. Can someone sanity check me on these two things? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.