From owner-freebsd-stable@FreeBSD.ORG  Sat Jan 28 23:11:46 2006
Return-Path: <owner-freebsd-stable@FreeBSD.ORG>
X-Original-To: freebsd-stable@FreeBSD.org
Delivered-To: freebsd-stable@FreeBSD.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 2ED9616A420
	for <freebsd-stable@FreeBSD.org>; Sat, 28 Jan 2006 23:11:46 +0000 (GMT)
	(envelope-from truckman@FreeBSD.org)
Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163])
	by mx1.FreeBSD.org (Postfix) with ESMTP id D150A43D46
	for <freebsd-stable@FreeBSD.org>; Sat, 28 Jan 2006 23:11:45 +0000 (GMT)
	(envelope-from truckman@FreeBSD.org)
Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2])
	by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id k0SNBYAr017640;
	Sat, 28 Jan 2006 15:11:38 -0800 (PST)
	(envelope-from truckman@FreeBSD.org)
Message-Id: <200601282311.k0SNBYAr017640@gw.catspoiler.org>
Date: Sat, 28 Jan 2006 15:11:34 -0800 (PST)
From: Don Lewis <truckman@FreeBSD.org>
To: dwmalone@maths.tcd.ie
In-Reply-To: <20060128104622.GA44760@walton.maths.tcd.ie>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Cc: freebsd-stable@FreeBSD.org, dlm-fb@weaselfish.com
Subject: Re: [5.4] mode bits changed by close(2)
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>, 
	<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
	<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 28 Jan 2006 23:11:46 -0000

On 28 Jan, David Malone wrote:
> On Fri, Jan 27, 2006 at 02:01:19PM -0700, dlm-fb@weaselfish.com wrote:
>> Sticking an fsync() in between the fchmod() and the close() causes the
>> bits to be cleared as a side-effect of the fsync().  Doing another
>> fchmod() after the fsync() produces the final expected set{u,g}id
>> results even after the close.  Unfortunately, fsync() is a rather
>> expensive operation.
> 
> There is code to clear the suid bits on a file when it is written
> to, and I guess this is being triggered when the write is flushed
> rather than when the write call is made. This would explain why
> flushing before the fsync stops the problem.

The last partial write is probably being cached by the client and not
being flushed to the server until the client calls close().  The server
is seeing the NFS write after it set the set{u,g}id bit(s) and is
clearing them in response to the write.

The sequence
	write()
	fsync()
	fchmod()
	close()
should work.

This oddity could be hidden from userland if fchmod() sync'ed the file
before setting the bits, but that doesn't change the performance impact.