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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Reply via email to