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(at)debis(dot)com (Jan Wieck) #