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>