Re: [HACKERS] idea: custom log_line_prefix components besides application_name
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] idea: custom log_line_prefix components besides application_name |
Дата | |
Msg-id | 26440.1494348481@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] idea: custom log_line_prefix components besidesapplication_name (David Fetter <david@fetter.org>) |
Ответы |
Re: [HACKERS] idea: custom log_line_prefix components besides application_name
Re: [HACKERS] idea: custom log_line_prefix components besidesapplication_name |
Список | pgsql-hackers |
David Fetter <david@fetter.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@anastigmatix.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
В списке pgsql-hackers по дате отправления: