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@debis.com (Jan Wieck) #