Re: [HACKERS] Table permissions problem

>
> > > Remember some tables are shared with all databases. Makes things more
> > > difficult.
> >
> > And that's why I suggested a uid/euid model over functions,
> > triggers and views, where the permission checks are done
> > against the function/view owner instead of the current user.
> > If nobody reverted things, this is already done for views
> > (pg_user vs pg_shadow). The ACL checks are done during the
> > rewrite.
> >
> > So CREATE VIEW or CREATE RULE could eventually use some trick
> > to get around the restrictions on pg_rewrite but ensure that
> > the rule owner is the one creating it. Pg_rewrite itself must
> > be protected, otherwise a user could change the ownership of
> > a view and get around access restrictions.
>
> Couldn't we do some permission checks on tables at runtime from the
> rewrite system ONLY when a table is being added or UPDATE is added to
> SELECT, etc?
>
> Would that solve the problem? Maybe not because you would have to rip
> apart the plan, wouldn't you?
>
> --
> Bruce Momjian | 830 Blythe Avenue

I checked it. It's all already there. The rewrite handler
checks for all the range table entries he adds to the query,
if the rule owner has the appropriate permissions
(read/write). And it sets the skipAcl field for these rte's
so the executor later will ignore them.

The only thing missing is that CREATE VIEW and CREATE RULE
require write access to pg_rewrite (create view does a create
table and create rule internally). But we cannot grant write
access on pg_rewrite to looser users. So I think a global
variable, turning off the whole ACL system temporary, would
do.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck(at)debis(dot)com (Jan Wieck) #