From owner-freebsd-standards@FreeBSD.ORG Fri Nov 16 00:27:50 2007 Return-Path: Delivered-To: standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F96A16A419 for ; Fri, 16 Nov 2007 00:27:50 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 880A313C4C5; Fri, 16 Nov 2007 00:27:49 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <473CE408.1030901@FreeBSD.org> Date: Fri, 16 Nov 2007 01:27:52 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Bruce Evans References: <473CC2A0.8020603@FreeBSD.org> <20071116110621.U10808@besplex.bde.org> In-Reply-To: <20071116110621.U10808@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: standards@FreeBSD.org Subject: Re: Variant behaviour from truncate over NFS and UFS X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2007 00:27:50 -0000 Bruce Evans wrote: > On Thu, 15 Nov 2007, Kris Kennaway wrote: > >> I came across the following variant behaviour. On NFS: >> >> hydra1# cd /nfs >> hydra1# touch foo >> hydra1# chmod a-w foo >> hydra1# ls -l foo >> -r--r--r-- 1 4294967294 wheel 0 Nov 15 21:57 foo >> hydra1# truncate -s 0 foo >> truncate: foo: Permission denied >> hydra1# chmod u+w foo >> hydra1# truncate -s 0 foo >> >> Compare to UFS: >> >> hydra1# cd /tmp >> hydra1# touch foo >> hydra1# chmod a-w foo >> hydra1# truncate -s 0 foo >> hydra1# ls -l foo >> -r--r--r-- 1 root wheel 0 Nov 15 21:57 foo >> >> Which is correct? > > Both, I think. truncate(2) requires write permission, and root always > has write permission, but root isn't really root for the nfs case. > > Anyway, the default of maproot=-2 gives much more annoying nonstandard > behaviour than this -- it often prevents root doing things that normal > users can do. Ah yes, thanks for clarifying. Kris