Date: Mon, 29 Oct 2001 08:35:35 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: obrien@FreeBSD.ORG Cc: Mike Barcroft <mike@FreeBSD.ORG>, void <float@firedrake.org>, Kris Kennaway <kris@obsecurity.org>, hackers@FreeBSD.ORG Subject: Re: syslogd and kqueue Message-ID: <3BDD8557.A2190693@mindspring.com> References: <20011026233957.A9925@parhelion.firedrake.org> <20011026200436.A61058@xor.obsecurity.org> <20011027043342.A18231@parhelion.firedrake.org> <20011027001704.B2586@coffee.q9media.com> <20011027002622.C2586@coffee.q9media.com> <20011028180643.B59388@dragon.nuxi.com> <3BDCCFB2.1E5CFC49@mindspring.com> <20011028202345.A60175@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David O'Brien wrote: > > If it created the file itself, there would be a potential > > race issue that would remain unresolved, which is hidden by > > the seperation of the create and the subsequent signal. > > Come again? > > 1. syslogd calls open(2) with O_CREAT. At this point syslogd happily > keeps the file open and writes to it. > 2. I rename the file. As we all know, syslogd keeps writing to its open > file. > 3. syslogd is HUP'ed, goto #1. > > No muss, no fuss. So where is the race? > Mike had the only justification so far -- that of permissions of the > file. Think multiple instances of syslogd. Mike's justification was also my justification; you'd have to change the configuration file format to get the same values. If syslogd is running as someone capable of opening files in a directory also does not necessarily imply the ability to create the file (otherwise you'd be able to dismiss Mike's objection with an fstat() after the hup, followed by the create using the same properties -- so Mike's objection is more subtle than it first appears, as well). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BDD8557.A2190693>