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
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() |