"David O'Brien" wrote: | On Sun, Oct 28, 2001 at 07:40:34PM -0800, Terry Lambert wrote: | > By using the rename/create/signal approach, syslogd is | > guaranteed to log new messages to the old file, despite the | > rename, until signalled to close and reopen the file (or a | > new file of another name, if syslog.conf is changed). | > | > 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.
Here's a proposal to cope with that. Add an optional sub-field to any action field in syslog.conf that begins with a slash, perhaps in the form `:0640:root:wheel'. If the syslog.conf file has this thing on the pathname, add O_CREAT to the open(2), and set the permissions and ownership as specified. If any of the three parts is missing, don't whine, but process the other parts. If the optional sub-field is completely missing (or has bad elements), stick to the old behaviour. This handles POLA, as older syslog.conf files will produce the same results as always; while those who read the additional comments in the new files can implement the new behaviour. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
