Re: [logs] Syslog payload format

avalonat_private

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.

Darren
_______________________________________________
LogAnalysis mailing list
LogAnalysisat_private
http://lists.shmoo.com/mailman/listinfo/loganalysis