2009/10/19 Andrew Dunstan <andrew@dunslane.net>:
>
>
> Pavel Stehule wrote:
>>
>> 2009/10/19 Andrew Dunstan <andrew@dunslane.net>:
>>
>>>
>>> Pavel Stehule wrote:
>>>
>>>>
>>>> 2009/10/19 Dave Page <dpage@pgadmin.org>:
>>>>
>>>>
>>>>>
>>>>> On Mon, Oct 19, 2009 at 8:54 AM, Pavel Stehule
>>>>> <pavel.stehule@gmail.com>
>>>>> wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> I dislike write access to app name guc for user too. It's not safe.
>>>>>> Maybe only super user can do it?
>>>>>>
>>>>>>
>>>>>
>>>>> That'll render it pretty useless, as most applications wouldn't then
>>>>> be able to set/reset it when it makes sense to do so.
>>>>>
>>>>>
>>>>
>>>> But application can do it simply via connection string, no? Mostly
>>>> applications has connection string in configuration, so I don't see
>>>> problem there. And if I would to allow access, then I could to wrap
>>>> setting to security definer function.
>>>>
>>>> I see this as security hole. It allows special SQL injection.
>>>>
>>>>
>>>>
>>>
>>> How is it any more a security hole than any other setting that the user
>>> can
>>> alter with an arbitrary string value (e.g. custom options)?
>>>
>>>
>>
>> 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.
>
good designed parsers will not have a problem. But lot of parser is
based in custom rules. And these rules should be not 100% safe. This
proposal increase risks.
Pavel
> And no, it is not at all the same as changing the client's IP address.
>
> cheers
>
> andrew
>