Re: idea: custom log_line_prefix components besides application_name

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Fetter <david(at)fetter(dot)org>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Chapman Flack <chap(at)anastigmatix(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: idea: custom log_line_prefix components besides application_name
Date: 2017-05-09 16:48:01
Message-ID: 26440.1494348481@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Fetter <david(at)fetter(dot)org> writes:
> 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.

Yeah. It's a bit hard to see a database's parser treating "Uni/**/ON"
as UNION, but if some stack someplace had a keyword check ahead of
a comment-stripping step, maybe that could do something useful.

> 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 don't think that's a problem: while psql will remove "--" and everything
following it until newline, it won't remove the newline. So there's still
a token boundary there. If we tried to strip /*...*/ comments we'd have
to be more careful.

As far as the actual thread topic goes, I tend to agree with Robert's
doubt that there's enough utility or consensus for this.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-05-09 17:09:30 Re: Adding support for Default partition in partitioning
Previous Message David Steele 2017-05-09 16:39:55 Re: Should pg_current_wal_location() become pg_current_wal_lsn()