Re: idea: custom log_line_prefix components besides application_name

On Fri, May 05, 2017 at 02:20:26PM -0400, Robert Haas wrote:
> On Thu, May 4, 2017 at 10:59 AM, Chapman Flack <chap(at)anastigmatix(dot)net> wrote:
> > invalid input syntax for integer: "21' && 1=2)) Uni/**/ON
> > SEl/**/eCT 0x646665743166657274,0x646665743266657274,
> > 0x646665743366657274 -- "
>
> Now that is choice. I wonder what specific database system that's
> targeting...

It could well be targeting some class of pipeline to the database,
too, for example one that removes comments and/or un-escapes.

It occurs to me that psql's habit of stripping out everything on a
line that follows a double dash might be vulnerable in this way, but
I wouldn't see such vulnerabilities as super easy to exploit, as psql
isn't usually exposed directly to input from the internet.

> > I just wonder if anybody thinks web apps, and therefore this
> > scenario, are common enough these days to maybe justify one or two
> > more GUCs with their own log_line_prefix escapes, such as
> > app_client_addr or app_user. Naturally they would only be as
> > reliable as the app setting them, and uninterpreted by PostgreSQL
> > itself, and so functionally no different from the uninterpreted
> > string already available as application_name. The benefit is
> > perhaps to be clearer than just overloading application_name to
> > carry two or three pieces of information (and perhaps privacy, if
> > you care about app user identities and source IPs showing up in ps
> > titles).
> >
> > Worth considering, or is application_name Good Enough?
>
> I mean, if there were a list of things that needed to propagated
> that was (1) lengthy and (2) universally agreed, then we'd probably
> want more than one field. But your list is pretty short, so I guess
> I don't see why you can't just join them together with a punctuation
> mark of your choice and call it good.
>
> I might be missing something, though.

That there isn't universal agreement probably points to wanting an
ability to place arbitrary fields in the logs, not just a
log_line_prefix. This would be made a good bit simpler by structuring
logs, by default, in some serialization a little easier to reason
about (and among other things, parse correctly) than CSV.

Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate