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
On 23/06/10 21:36, Robert Haas wrote:
On Mon, Jun 21, 2010 at 7:50 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Mon, Jun 21, 2010 at 7:50 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
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
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
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 seperate
(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?
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
On 09/06/10 17:34, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com 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
On 09/06/10 17:34, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com 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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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.
Kris Jurka bo...@ejurka.com 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
On Wed, Jun 9, 2010 at 1:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Kris Jurka bo...@ejurka.com 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
Robert Haas robertmh...@gmail.com writes:
On Wed, Jun 9, 2010 at 1:34 PM, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Jun 9, 2010 at 2:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Jun 9, 2010 at 1:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Yes, it's not a trivial fix either. We'll have to provide functions or
views that replace the current usages without
Robert Haas robertmh...@gmail.com writes:
On Wed, Jun 9, 2010 at 2:04 PM, Tom Lane t...@sss.pgh.pa.us 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
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
18 matches
Mail list logo
