From: | Dave Page <dpage(at)pgadmin(dot)org> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Application name patch - v2 |
Date: | 2009-10-19 08:44:46 |
Message-ID: | 937d27e10910190144kb929550u716b4a8c17fb4315@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Oct 19, 2009 at 9:36 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> Then we have to divide this value to two independent values like
> application_name and application_state.
How does that make any difference? That just means we have two values,
at least one of which is still userset, and means an additional field
in the logs and stats view etc.
>>> I see this as security hole. It allows special SQL injection.
>>
>> How so?
>>
> You change identity. If any application is vulnerable to SQL
> injection, then this value is nice goal.
Are you saying that if your application is vulnerable, then the user
may be able to masquerade as something else? If that's the case (and
it's a problem for you), then there's a good chance you've got far
bigger problems to worry about.
This is not intended as a security mechanism, merely as a convenient
way to identify what a backend is being used for. It doesn't remove
any of the existing properties of the connection that the user cannot
change (PID, current query, current user, host IP etc).
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2009-10-19 08:57:15 | Re: Application name patch - v2 |
Previous Message | Andrew Dunstan | 2009-10-19 08:42:49 | Re: Application name patch - v2 |