Prev: [HACKERS] ERROR: argument to pg_get_expr() must come from system catalogs
Next: bg worker: overview
From: Thom Brown on 13 Jul 2010 11:44
On 13 July 2010 16:31, Dave Page <dpage(a)pgadmin.org> wrote:
> We had a report of the above error from a pgAdmin user testing
> 1.12.0b3 with PG 9.0b3. The (highly simplified) query below works fine
> as a superuser:
>
> SELECT pg_get_expr(proargdefaults, 'pg_catalog.pg_class'::regclass)
> �FROM pg_proc pr
> �LEFT OUTER JOIN pg_description des ON des.objoid=pr.oid
>
> Run as a regular user though, we get the error. If I remove the join,
> it works fine as the normal user. This is in a database owned by the
> regular user.
>
> Am I missing something obvious, or is there a bug here? pg_get_expr is
> used pretty extensively in pgAdmin, so we're obviously keen to ensure
> it works :-)
>

I tested this on both beta2 and beta3 and can confirm that it works on
beta2 but produces the following error in beta3:

********** Error **********

ERROR: argument to pg_get_expr() must come from system catalogs
SQL state: 42501

Thom

--
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: Thom Brown on 13 Jul 2010 11:48
On 13 July 2010 16:44, Thom Brown <thombrown(a)gmail.com> wrote:
> On 13 July 2010 16:31, Dave Page <dpage(a)pgadmin.org> wrote:
>> We had a report of the above error from a pgAdmin user testing
>> 1.12.0b3 with PG 9.0b3. The (highly simplified) query below works fine
>> as a superuser:
>>
>> SELECT pg_get_expr(proargdefaults, 'pg_catalog.pg_class'::regclass)
>> �FROM pg_proc pr
>> �LEFT OUTER JOIN pg_description des ON des.objoid=pr.oid
>>
>> Run as a regular user though, we get the error. If I remove the join,
>> it works fine as the normal user. This is in a database owned by the
>> regular user.
>>
>> Am I missing something obvious, or is there a bug here? pg_get_expr is
>> used pretty extensively in pgAdmin, so we're obviously keen to ensure
>> it works :-)
>>
>
> I tested this on both beta2 and beta3 and can confirm that it works on
> beta2 but produces the following error in beta3:
>
> ********** Error **********
>
> ERROR: argument to pg_get_expr() must come from system catalogs
> SQL state: 42501
>
> Thom
>

And here's why:
http://archives.postgresql.org/pgsql-committers/2010-06/msg00259.php

"stringToNode() and deparse_expression_pretty() crash on invalid input,
but we have nevertheless exposed them to users via pg_get_expr(). It would
be too much maintenance effort to rigorously check the input, so put a hack
in place instead to restrict pg_get_expr() so that the argument must come
from one of the system catalog columns known to contain valid expressions."

Thom

--
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: Dave Page on 13 Jul 2010 11:50
On Tue, Jul 13, 2010 at 4:48 PM, Thom Brown <thombrown(a)gmail.com> wrote:
> On 13 July 2010 16:44, Thom Brown <thombrown(a)gmail.com> wrote:
>> On 13 July 2010 16:31, Dave Page <dpage(a)pgadmin.org> wrote:
>>> We had a report of the above error from a pgAdmin user testing
>>> 1.12.0b3 with PG 9.0b3. The (highly simplified) query below works fine
>>> as a superuser:
>>>
>>> SELECT pg_get_expr(proargdefaults, 'pg_catalog.pg_class'::regclass)
>>> �FROM pg_proc pr
>>> �LEFT OUTER JOIN pg_description des ON des.objoid=pr.oid
>>>
>>> Run as a regular user though, we get the error. If I remove the join,
>>> it works fine as the normal user. This is in a database owned by the
>>> regular user.
>>>
>>> Am I missing something obvious, or is there a bug here? pg_get_expr is
>>> used pretty extensively in pgAdmin, so we're obviously keen to ensure
>>> it works :-)
>>>
>>
>> I tested this on both beta2 and beta3 and can confirm that it works on
>> beta2 but produces the following error in beta3:
>>
>> ********** Error **********
>>
>> ERROR: argument to pg_get_expr() must come from system catalogs
>> SQL state: 42501
>>
>> Thom
>>
>
> And here's why:
> http://archives.postgresql.org/pgsql-committers/2010-06/msg00259.php
>
> "stringToNode() and deparse_expression_pretty() crash on invalid input,
> but we have nevertheless exposed them to users via pg_get_expr(). It would
> be too much maintenance effort to rigorously check the input, so put a hack
> in place instead to restrict pg_get_expr() so that the argument must come
> from one of the system catalog columns known to contain valid expressions."

Yeah, I recall that - but... the argument *is* coming from the system
catalogs, and why is the error only thrown for a non-superuser, when
the query includes the join?

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgres Company

--
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: Thom Brown on 13 Jul 2010 11:56
On 13 July 2010 16:50, Dave Page <dpage(a)pgadmin.org> wrote:
> On Tue, Jul 13, 2010 at 4:48 PM, Thom Brown <thombrown(a)gmail.com> wrote:
>> On 13 July 2010 16:44, Thom Brown <thombrown(a)gmail.com> wrote:
>>> On 13 July 2010 16:31, Dave Page <dpage(a)pgadmin.org> wrote:
>>>> We had a report of the above error from a pgAdmin user testing
>>>> 1.12.0b3 with PG 9.0b3. The (highly simplified) query below works fine
>>>> as a superuser:
>>>>
>>>> SELECT pg_get_expr(proargdefaults, 'pg_catalog.pg_class'::regclass)
>>>> �FROM pg_proc pr
>>>> �LEFT OUTER JOIN pg_description des ON des.objoid=pr.oid
>>>>
>>>> Run as a regular user though, we get the error. If I remove the join,
>>>> it works fine as the normal user. This is in a database owned by the
>>>> regular user.
>>>>
>>>> Am I missing something obvious, or is there a bug here? pg_get_expr is
>>>> used pretty extensively in pgAdmin, so we're obviously keen to ensure
>>>> it works :-)
>>>>
>>>
>>> I tested this on both beta2 and beta3 and can confirm that it works on
>>> beta2 but produces the following error in beta3:
>>>
>>> ********** Error **********
>>>
>>> ERROR: argument to pg_get_expr() must come from system catalogs
>>> SQL state: 42501
>>>
>>> Thom
>>>
>>
>> And here's why:
>> http://archives.postgresql.org/pgsql-committers/2010-06/msg00259.php
>>
>> "stringToNode() and deparse_expression_pretty() crash on invalid input,
>> but we have nevertheless exposed them to users via pg_get_expr(). It would
>> be too much maintenance effort to rigorously check the input, so put a hack
>> in place instead to restrict pg_get_expr() so that the argument must come
>> from one of the system catalog columns known to contain valid expressions."
>
> Yeah, I recall that - but... the argument *is* coming from the system
> catalogs, and why is the error only thrown for a non-superuser, when
> the query includes the join?
>

I works if you use pr.proargdefaults so not unresolvable. Maybe it's
because it can't tell where the column's coming from at that point?

Thom

--
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: Dave Page on 13 Jul 2010 12:00
On Tue, Jul 13, 2010 at 4:56 PM, Thom Brown <thombrown(a)gmail.com> wrote:

> I works if you use pr.proargdefaults so not unresolvable. �Maybe it's
> because it can't tell where the column's coming from at that point?

Hmm, so it does. It still seems like a bug though - why should it be
able to resolve the column based on whether you're a superuser or not,
just because it's not qualified?


--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgres Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 |  Next  |  Last
Pages: 1 2 3 4
Prev: [HACKERS] ERROR: argument to pg_get_expr() must come from system catalogs
Next: bg worker: overview