Re: [HACKERS] Table permissions problem - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [HACKERS] Table permissions problem
Date
Msg-id 199808131136.HAA08446@candle.pha.pa.us
Whole thread Raw
In response to Re: [HACKERS] Table permissions problem  (jwieck@debis.com (Jan Wieck))
Responses Re: [HACKERS] Table permissions problem  (jwieck@debis.com (Jan Wieck))
List pgsql-hackers
> > 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
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

pgsql-hackers by date:

Previous
From: jwieck@debis.com (Jan Wieck)
Date:
Subject: tuple return from function
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] tuple return from function