Re: [HACKERS] Running pgindent - Mailing list pgsql-hackers

>
>
> Bruce wrote:
> > >
> > >     Got very close to the view permission override - just a vew hours
> > >     for me :-)
> >
> > Great.  I was thinking about this, and I think it would be best if the
> > view permissions were checked as the view owner at view USE time, not
> > view CREATION time, that way if permissions on the base tables change,
> > the permissions are properly honored.
>
>     Did it that way as it looked better for me too. :-)

Good.

>
> >
> > I think the range table idea is good, so there is an OWNER field on each
> > range table which defaults to the current user.  As views are replaced
> > by base tables in the rewrite system, the owner can be changed to the
> > owner of the view.  The issue is whether the range table entry will be
> > available in the executor for you to access that owner field.  But at
> > this point, any fix for this would be great.  People are asking for this
> > view permissions thing.
>
>     Done   much   easier.   Appended  a  bool  field  aclSkip  to
>     RangeTblEntry that defaults to false due to makenode().  When
>     the  rewriting  system finds a rule on select on the relation
>     level, with exactly one action, the actions command type is a
>     select  which  is  instead  (wow) it is a view. This time the
>     rewrite handler checks acl for the range table entries in the
>     rules  action  against  the owner of the table the rule is on
>     (the view itself). On success it sets aclSkip to true.
>
>     Later the  executor  in  ExecCheckPerms()  just  skips  these
>     entries.   Since one range table entry for the view itself is
>     left without the aclSkip  set  the  executor  checks  if  the
>     current  user  has  access  rights for the view. But it skips
>     those entries appended to the  range  table  by  the  rewrite
>     handler accessing the real tables in question.
>
>     One little thing isn't covered then. User A creates a view on
>     a table he revoked from world and grants access to  the  view
>     only to user B.  Now user B can create another view selecting
>     A's view and grant that to world and this would  do  it.  But
>     since  any  user  that  can read a view could simply copy the
>     data into another table and grant that to world I don't see a
>     really security problem here. Granting access to user implies
>     IMHO you can trust that user.

This sounds great to me.  As you have added to RangeTableEntry, I assume
you also added the needed fields to copyfuncs.c/outfuncs.c/makefuncs.c
and anywhere else that needs it.  I will add this to the developers FAQ.

>
> >
> > Also, this makes non-super-user created views even harder, because if
> > people can create their own views, they can change the owner field to
> > anyone they want to, but that is for later.
>
>     Do they - hmmm that's not good. But  there  could  be  a  way
>     round.  Really for later but let's keep the solution in mind.
>
>     We add a bool to pg_class that let's the rewrite handler know
>     if  he really should set the aclSkip defaulting to false.  On
>     ownership changes this flag is reset to false  and  only  the
>     owner or superusers might set it.

No, that is not what I was saying.  If they can create views, the can
change pg_rewrite, and because we now take the view as the owners
permission granting, someone could change anything in pg_rewrite and
make it look like it is a view of someone else.  They could change the
view text to look at pg_user, for example.

--
Bruce Momjian
maillist@candle.pha.pa.us