pgsql: Add a security_barrier option for views.
Add a security_barrier option for views.
When a view is marked as a security barrier, it will not be pulled up
into the containing query, and no quals will be pushed down into it,
so that no function or operator chosen by the user can be applied to
rows not exposed by the view. Views not configured with this
option cannot provide robust row-level security, but will perform far
better.
Patch by KaiGai Kohei; original problem report by Heikki Linnakangas
(in October 2009!). Review (in earlier versions) by Noah Misch and
others. Design advice by Tom Lane and myself. Further review and
cleanup by me.
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/0e4611c0234d89e288a53351f775c59522baed7c
Modified Files
--------------
doc/src/sgml/ref/alter_view.sgml | 20 +++++++++
doc/src/sgml/ref/create_view.sgml | 13 ++++++
doc/src/sgml/rules.sgml | 39 ++++++++++++++++-
src/backend/access/common/reloptions.c | 17 +++++++-
src/backend/commands/tablecmds.c | 66 ++++++++++++++++++++++-------
src/backend/commands/view.c | 26 ++++++++---
src/backend/nodes/copyfuncs.c | 1 +
src/backend/nodes/equalfuncs.c | 1 +
src/backend/nodes/outfuncs.c | 1 +
src/backend/nodes/readfuncs.c | 1 +
src/backend/optimizer/path/allpaths.c | 14 ++++++
src/backend/optimizer/prep/prepjointree.c | 2 +
src/backend/parser/gram.y | 10 +++--
src/backend/rewrite/rewriteHandler.c | 1 +
src/backend/utils/adt/selfuncs.c | 13 ++++++
src/backend/utils/cache/relcache.c | 1 +
src/bin/pg_dump/pg_dump.c | 6 ++-
src/include/access/reloptions.h | 3 +-
src/include/nodes/parsenodes.h | 3 +
src/include/utils/rel.h | 9 ++++
src/test/regress/expected/create_view.out | 55 +++++++++++++++++++++++-
src/test/regress/sql/create_view.sql | 33 ++++++++++++++
22 files changed, 300 insertions(+), 35 deletions(-)
Robert Haas <rhaas@postgresql.org> writes:
Add a security_barrier option for views.
Where's the catversion bump for having broken stored rules/views?
regards, tom lane
Excerpts from Tom Lane's message of jue dic 22 18:39:18 -0300 2011:
Robert Haas <rhaas@postgresql.org> writes:
Add a security_barrier option for views.
Where's the catversion bump for having broken stored rules/views?
I'm starting to wonder if we should have a git hook of some sort to
check for this ...
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Thu, Dec 22, 2011 at 4:17 PM, Robert Haas <rhaas@postgresql.org> wrote:
Add a security_barrier option for views.
you have some docs typos here, for the rest: cool.
doc/src/sgml/ref/create_view.sgml
"""
+ This clause specifies optional parameters for a view; currently, the
+ only suppored parameter name is <literal>security_barrier</literal>,
"""
should say "supported parameter"doc/src/sgml/rules.sgml
"""
+ the view. This prevents maliciously-chosen functions and operators from
+ being invoked on rows until afterthe view has done its work. For
"""
should say "until after the view"?"""
+ in the limited sense that the contents of the invisible tuples will not
+ passed to possibly-insecure functions. The user may well have other means
"""
should say "will not be passed"?--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación
Alvaro Herrera <alvherre@commandprompt.com> writes:
Excerpts from Tom Lane's message of jue dic 22 18:39:18 -0300 2011:
Robert Haas <rhaas@postgresql.org> writes:
Add a security_barrier option for views.
Where's the catversion bump for having broken stored rules/views?
I'm starting to wonder if we should have a git hook of some sort to
check for this ...
Dunno, how would you automate that?
My rule of thumb is that touching either src/include/catalog/* or
readfuncs.c probably means you need a catversion bump. It's the
"probably" that's a problem for automated enforcement. I don't
want unnecessary catversion bumps happening just because some tool
is preventing a commit.
regards, tom lane
Excerpts from Tom Lane's message of jue dic 22 19:09:54 -0300 2011:
Alvaro Herrera <alvherre@commandprompt.com> writes:
Excerpts from Tom Lane's message of jue dic 22 18:39:18 -0300 2011:
Robert Haas <rhaas@postgresql.org> writes:
Add a security_barrier option for views.
Where's the catversion bump for having broken stored rules/views?
I'm starting to wonder if we should have a git hook of some sort to
check for this ...Dunno, how would you automate that?
My rule of thumb is that touching either src/include/catalog/* or
readfuncs.c probably means you need a catversion bump. It's the
"probably" that's a problem for automated enforcement. I don't
want unnecessary catversion bumps happening just because some tool
is preventing a commit.
Yeah, maybe this belongs in a tool local to each developer. I run a
script here "git-safe-push" (yes, from Magnus) that, currently, displays
the commits I have for pushing, so that I can double check that I'm not
pushing something improper. I guess I could integrate something that if
there's a hunk touching src/include/catalog, it raises a warning and
nothing more, so I can easily ignore it if it's wrong.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support