On 23/06/10 21:36, Robert Haas wrote:
On Mon, Jun 21, 2010 at 7:50 PM, Heikki Linnakangas
wrote:
On 15/06/10 10:31, Heikki Linnakangas wrote:
You could avoid changing the meaning of fn_expr by putting the check in
the parse analysis phase, into transformFuncCall(). That would feel
safer at l
On 15/06/10 15:19, Florian Pflug wrote:
On Jun 15, 2010, at 9:31 , Heikki Linnakangas wrote:
You could avoid changing the meaning of fn_expr by putting the check in the
parse analysis phase, into transformFuncCall(). That would feel safer at least
for back-branches.
For 9.0, wouldn't a clean
On Mon, Jun 21, 2010 at 7:50 PM, Heikki Linnakangas
wrote:
> On 15/06/10 10:31, Heikki Linnakangas wrote:
>>
>> You could avoid changing the meaning of fn_expr by putting the check in
>> the parse analysis phase, into transformFuncCall(). That would feel
>> safer at least for back-branches.
>
> He
On 15/06/10 10:31, Heikki Linnakangas wrote:
You could avoid changing the meaning of fn_expr by putting the check in
the parse analysis phase, into transformFuncCall(). That would feel
safer at least for back-branches.
Here's a patch using that approach.
I grepped through PostgreSQL and pgadmi
On Jun 15, 2010, at 9:31 , Heikki Linnakangas wrote:
> You could avoid changing the meaning of fn_expr by putting the check in the
> parse analysis phase, into transformFuncCall(). That would feel safer at
> least for back-branches.
For 9.0, wouldn't a cleaner way to accomplish this be a seperat
On 10/06/10 00:24, Tom Lane wrote:
I wrote:
[ thinks for awhile... ] I wonder whether there is any way of locking
down pg_get_expr so that it throws an error if called with anything
except a suitable field from one of the system catalogs.
I did a bit of research into this idea. It looks at l
I wrote:
> [ thinks for awhile... ] I wonder whether there is any way of locking
> down pg_get_expr so that it throws an error if called with anything
> except a suitable field from one of the system catalogs.
I did a bit of research into this idea. It looks at least somewhat
feasible:
* All PG
Robert Haas writes:
> On Wed, Jun 9, 2010 at 2:04 PM, Tom Lane wrote:
>> Well, ideally yes, but if it's not actually *secure* then there's no
>> point --- and I don't believe that the approach of making readfuncs.c
>> secure against malicious input has the proverbial snowball's chance
>> of ever
On Wed, Jun 9, 2010 at 2:04 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jun 9, 2010 at 1:34 PM, Tom Lane wrote:
>>> Yes, it's not a trivial fix either. We'll have to provide functions or
>>> views that replace the current usages without letting the user insert
>>> untrusted strings.
>
Robert Haas writes:
> On Wed, Jun 9, 2010 at 1:34 PM, Tom Lane wrote:
>> Yes, it's not a trivial fix either. We'll have to provide functions or
>> views that replace the current usages without letting the user insert
>> untrusted strings.
> Maybe I'm all wet here, but don't we need to come up w
On Wed, Jun 9, 2010 at 1:34 PM, Tom Lane wrote:
> Kris Jurka writes:
>> On Wed, 9 Jun 2010, Heikki Linnakangas wrote:
>>> Are you thinking we should retrict pg_get_expr() to superusers then?
>
>> That seems like it will cause problems for both pg_dump and drivers which
>> want to return metadata
Kris Jurka writes:
> On Wed, 9 Jun 2010, Heikki Linnakangas wrote:
>> Are you thinking we should retrict pg_get_expr() to superusers then?
> That seems like it will cause problems for both pg_dump and drivers which
> want to return metadata as pg_get_expr has been the recommended way of
> fetch
On Wed, 9 Jun 2010, Heikki Linnakangas wrote:
Are you thinking we should retrict pg_get_expr() to superusers then?
That seems like it will cause problems for both pg_dump and drivers which
want to return metadata as pg_get_expr has been the recommended way of
fetching this information.
Heikki Linnakangas writes:
> On 09/06/10 17:34, Tom Lane wrote:
>> I think #1 is a fool's errand. There is far too much structure to a
>> node tree that is outside the scope of what readfuncs.c is capable of
>> understanding.
> That's why I said that ruleutils.c will need to understand and compl
On 09/06/10 17:34, Tom Lane wrote:
Heikki Linnakangas writes:
We have two options:
1. Make pg_get_expr() handle arbitrary (possibly even malicious) input
gracefully.
2. Restrict pg_get_expr() to superusers only.
I think #1 is a fool's errand. There is far too much structure to a
node t
On 09/06/10 17:34, Tom Lane wrote:
Heikki Linnakangas writes:
We have two options:
1. Make pg_get_expr() handle arbitrary (possibly even malicious) input
gracefully.
2. Restrict pg_get_expr() to superusers only.
I think #1 is a fool's errand. There is far too much structure to a
node t
Heikki Linnakangas writes:
> We have two options:
> 1. Make pg_get_expr() handle arbitrary (possibly even malicious) input
> gracefully.
> 2. Restrict pg_get_expr() to superusers only.
I think #1 is a fool's errand. There is far too much structure to a
node tree that is outside the scope of w
(moving to pgsql-hackers)
On 03/06/10 10:37, Heikki Linnakangas wrote:
However, I'm afraid we're lacking in input validation of read-funcs in
general. ...
>
Does anyone have an idea on how
to validate the input in a more wholesale fashion, so that we don't need
to plug these holes one by one?
18 matches
Mail list logo
