Horton

Re: 8.4 release planning

Kouhei Kaigai <kaigai@ak.jp.nec.com>

View thread View on postgr.es
From: KaiGai Kohei <kaigai@ak.jp.nec.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Simon Riggs <simon@2ndquadrant.com>, Joshua Brindle <method@manicmethod.com>, Ron Mayer <rm_pg@cheapcomplexdevices.com>, Josh Berkus <josh@agliodbs.com>, "Joshua D. Drake" <jd@commandprompt.com>, Merlin Moncure <mmoncure@gmail.com>, "Jonah H. Harris" <jonah.harris@gmail.com>, Gregory Stark <stark@enterprisedb.com>, Bruce Momjian <bruce@momjian.us>, Bernd Helmle <mailings@oopsware.de>, Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
Date: 2009-01-28T04:41:17Z
Lists: pgsql-hackers 
Tom Lane wrote:
> The flaw in that argument is that as you are doing it, the
> de-optimization only happens on queries that actually need the behavior.
> As the SEPostgres patch is constructed, the planner could *never* trust
> an FK for optimization since it would have no way to know whether row
> level permissions might be present (perhaps only for some rows) at
> execution time.

Is the "never" is really correct?

In the following case, it is necessary not to apply optimization:

- SE-PostgreSQL is working, and its row-level access controls
  are available (sepostgresql_row_level=on).
- Row-level ACL is available on the target relation.
  It is controlable via table option.

So, it is necessary to add a new security hook to give a hint
the optimizer.
Sorry, I overlooked this optimization. But is is not a fundamental
design issue. PGACE already has a hook to give a hint to optimizer.
It will be a similar one.

See, pgaceAllowFunctionInlined(...);
  http://code.google.com/p/sepgsql/source/browse/trunk/sepgsql/src/backend/security/pgaceHooks.c#948

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>