Re: [logs] Syslog payload format

From: Darren Reed (avalonat_private)
Date: Thu Jan 02 2003 - 01:48:12 PST

  • Next message: Balazs Scheidler: "Re: [logs] Syslog payload format"

    In some mail from Balazs Scheidler, sie said:
    > > > 2) create a handy interface for the programmer to format values
    > > [...]
    > > 
    > > Now if this were java, each tag would be an object and the tag/value
    > > pair would just be the result of serialising it.
    > > 
    > > Again, I don't necessarily want the programmer deciding how to format
    > > the values aside from saying what type of data it is.
    > > 
    > > I don't want to see this kind of thing:
    > > "srchost", "%16s", caller
    > hmm... I know it's a problem to open another possibility for format string
    > attacks. But forcing the programmer to format values first and emit log
    > message later makes the interface difficult to use. You'd see code snippets
    > like this then:
    > char buf1[256], buf2[256];
    > snprintf(buf, sizeof(buf), "%d", fd);
    > strlcpy(buf2, inet_ntoa(ip), sizeof(buf2));
    > xnewsyslog(..., "new connection accepted",
    >            IPADDR, buf2,
    > 	   PEERFD, buf1);
    > my tag naming is not fortunate, but the point is: some kind of formatting is
    > often required. Formatting is usually done with printf-like functions.
    The problem you have there is you're not telling xnewsyslog() about
    what type of data is being passed so of course you have this problem.
    You're assuming that "IPADDR" or "PEERFD" is a complete description
    of the data - well, in this case it is, I suppose as it appears to
    be a "char []" data object.
    By passing the value and what type of value it is, the log function
    is able to work out how to use it in the best way for it.  All we
    want application people to do is pass data to the log function and
    describe what sort of data it is.  We currently are dealing with a
    problem created by letting programmers format log data themselves,
    rather than describe it.
    The problem with the above is you're converting everything into a string
    at the library interface and that may not be desirable further on.
    LogAnalysis mailing list

    This archive was generated by hypermail 2b30 : Thu Jan 02 2003 - 08:15:44 PST