On Fri, Jan 27, 2006 at 02:01:19PM -0700, [EMAIL PROTECTED] 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.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
