Re: [HACKERS] idea: custom log_line_prefix components besidesapplication_name
От | David Fetter |
---|---|
Тема | Re: [HACKERS] idea: custom log_line_prefix components besidesapplication_name |
Дата | |
Msg-id | 20170509144740.GA11192@fetter.org обсуждение исходный текст |
Ответ на | Re: [HACKERS] idea: custom log_line_prefix components besides application_name (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] idea: custom log_line_prefix components besides application_name
|
Список | pgsql-hackers |
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. 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
В списке pgsql-hackers по дате отправления: