[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190115041240.GF23599@brightrain.aerifal.cx>
Date: Mon, 14 Jan 2019 23:12:40 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Use local time in syslog() function
On Tue, Jan 15, 2019 at 12:02:25AM +0100, Szabolcs Nagy wrote:
> * Rich Felker <dalias@...c.org> [2019-01-14 15:27:26 -0500]:
> > On Mon, Jan 14, 2019 at 08:53:45PM +0100, Michael Kaufmann wrote:
> > > >>I have found a bug in the implementation of syslog(). It should use
> > > >>the local time instead of UTC when sending the message to /dev/log.
> > > >>So in src/misc/syslog.c, the call to gmtime_r() should be replaced
> > > >>with localtime_r().
> > > >
> > > >This is not a bug; rather, use of local time there in glibc and other
> > > >systems is a bug. Local time varies by the sending process and
> > > >produces inconsistent and uninterpretable log messages. Moreover the
> > > >syslog() function is not specified to depend on the environment and
> > > >thereby is not allowed to call any function whose behavior is
> > > >dependant on the environment.
> > >
> > > Thank you for responding!
> > >
> > > I agree that GMT would have been a better choice, but I think local
> > > time is also mandated by RFC 3164,
> > > https://tools.ietf.org/html/rfc3164#section-4.1.2 : "The TIMESTAMP
> > > field is the local time". Or does this RFC not apply for syslog() on
> > > Linux?
>
> note that rfc is deprecated by
>
> https://tools.ietf.org/html/rfc5424
Thanks for finding that!
> which has a timestamp format that always includes zone information
> and i see no local time requirement any more, it also says
>
> The TIMESTAMP described in RFC 3164 offers less precision than the
> timestamp specified in this document. It also lacks the year and
> time zone information. If a message formatted according to this
> document needs to be reformatted to be in RFC 3164 format, it is
> suggested that the originator's local time zone be used, and the time
> zone information and the year be dropped. If an RFC 3164 formatted
> message is received and must be transformed to be compliant to this
> document, the current year should be added and the time zone of the
> relay or collector MAY be used.
>
> musl uses the old format, i don't know if existing tools depend on
> this, if not then musl should use the unambigous timestamp format.
I'm all for updating to the new format if there are no problems with
doing so, and expect it might fix whatever problems people are having
from timestamps being UTC (since syslogd would be able to see that
they are and reinterpret them however it likes).
Based on the obsolete RFC, I don't think there would be problems --
3164 makes it clear that the receiving process is supposed to accept
any message format even if it does not match the expected field
structure. Can anyone offer further insight into whether we might
break things for anyone?
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
