Date: Sat, 28 Jan 2006 10:46:22 +0000 From: David Malone <dwmalone@maths.tcd.ie> To: dlm-fb@weaselfish.com Cc: freebsd-stable@freebsd.org Subject: Re: [5.4] mode bits changed by close(2) Message-ID: <20060128104622.GA44760@walton.maths.tcd.ie> In-Reply-To: <200601272101.k0RL1JB09430@green-dome.village.org> References: <200601272101.k0RL1JB09430@green-dome.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
I've a feeling that it may be difficult to fix this and still have
the suid bits cleared if someone writes to a file via mmap, but I'm
not completly sure.
David.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060128104622.GA44760>