Thread: 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