Re: [HACKERS] Table permissions problem

>
> > Thus spake Bruce Momjian
> > > > I have since found out that it was changed so that no one, not even the
> > > > owner, had full privs on the tables.  I went in and changed my code
> > > > to grant ALL on each database to the db owner.  Everything is fine
> > > > except that I still can't create a view.  I still  get that "pg_rewrite:
> > > > Permission denied." error.  Any ideas?
> > > >
> > >
> > > Only superuser.  From TODO:
> > >
> > >     CREATE VIEW requires super-user priviledge
> > >
> > > This is because someone who can modify pg_rewrite can create their own
> > > view to modify any table.
> >
> > Hmm.  That makes it difficult.  I would like to build databases from
> > scripts.  I guess I can build them as the super user.
> >
> > Shouldn't the database owner have more privs then someone using the
> > database?  Is that what that TODO item is actually suggesting?
>
> 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.


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) #