Date: Sat, 28 Jan 2006 15:11:34 -0800 (PST) From: Don Lewis <truckman@FreeBSD.org> To: dwmalone@maths.tcd.ie Cc: freebsd-stable@FreeBSD.org, dlm-fb@weaselfish.com Subject: Re: [5.4] mode bits changed by close(2) Message-ID: <200601282311.k0SNBYAr017640@gw.catspoiler.org> In-Reply-To: <20060128104622.GA44760@walton.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200601282311.k0SNBYAr017640>