Prev: Hot standby status
Next: per table random-page-cost?
From: Pavel Stehule on 19 Oct 2009 05:45 2009/10/19 Dimitri Fontaine <dfontaine(a)hi-media.com>: > Andrew Dunstan <andrew(a)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. sure, you have to fix fulnerable application. But with some unsophisticated using %a and using wrong tools, the people can be blind and don't register an SQL injection attack. > > +1 for user settable GUC for setting application name. > -- > dim > -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Pavel Stehule on 19 Oct 2009 09:12 > >  -- monthly_report monthly_process.py:524 >  select wev from foo; > > This feature would be very handy, but not if it requires special permission > to use it. Superuser permission could not be a problem. Simple security definer function can do it. Regards Pavel > > -dg > > > -- > David Gould    daveg(a)sonic.net    510 536 1443   510 282 0869 > If simplicity worked, the world would be overrun with insects. > -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: David Fetter on 19 Oct 2009 10:17 On Mon, Oct 19, 2009 at 11:39:58AM +0100, Dave Page wrote: > Excuse me one moment whilst I pick myself up from the floor :-) Heh! > Can you imagine what a maintenance nightmare that would soon become? Only vaguely, and that's enough. > Please bear in mind that this feature is based on similar features in > other DBMSs (and in fact, a feature in the JDBC spec) Could you point to a reference for this? It could help the rest of us see what you're aiming for even better :) Cheers, David. -- David Fetter <david(a)fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter(a)gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Stephen Frost on 19 Oct 2009 10:33 * Pavel Stehule (pavel.stehule(a)gmail.com) wrote: > Superuser permission could not be a problem. Simple security definer > function can do it. Then you've defeated the point of making it superuser-only. I don't think that changing the app name deserves a warning, to be perfectly honest. Notice should be sufficient. Thanks, Stephen
From: Tom Lane on 19 Oct 2009 10:36
Dave Page <dpage(a)pgadmin.org> writes: > On Mon, Oct 19, 2009 at 12:57 PM, Pavel Stehule <pavel.stehule(a)gmail.com> wrote: >> I thing, so change of original name should generate warning. > Well, if other people think that's necessary, it's certainly possible. I think Pavel's entire line of argument is utter nonsense. He's setting up a straw man that has nothing to do with any actually likely use of the variable. I do agree with Peter's concerns about limiting the character set of the name string, and maybe there should be some sort of length limit too. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |