Re: Application name patch - v2 - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Application name patch - v2
Date
Msg-id 87iqeb20bz.fsf@hi-media-techno.com
Whole thread Raw
In response to Re: Application name patch - v2  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Application name patch - v2
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> Pavel Stehule wrote:
>> Others GUC has not important role in logs. It's similar as possibility
>> to change client IP address.
>
> That doesn't even remotely answer the question. How is such a thing a vector
> for an SQL injection attack, that does not apply to other GUCs? If your
> answer is that log parsers will try to inject the values, then it those
> programs that need to be fixed, rather than restricting this facility in a
> way that will make it close to pointless.

That's not how I parse Pavel's worries. I think what's he telling here
is that seeing how the new GUC will get used (filtering logs), it
happens that if you're vulnerable to SQL injection it could be worse
with the application name setting than without, because attacker would
hide its injections under a filtered-out application name.

Not sure my saying is easier to parse than Pavel's, btw...

> And no, it is not at all the same as changing the client's IP address.

If you filter logs by IP to detect attackers, and will filter by
application name in the future, I can see how it compares.

Now, I don't think Pavel's worries have much weight here because if
you're vulnerable to SQL injection you want to first fix this. And you
will want to give different (sub-)application names from within the same
connection, and the easier way to provide that is to change the GUC
value.

+1 for user settable GUC for setting application name.
-- 
dim


pgsql-hackers by date:

Previous
From: daveg
Date:
Subject: Re: Application name patch - v2
Next
From: Pavel Stehule
Date:
Subject: Re: Application name patch - v2