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. :-)

>
> 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.

>
> 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.


Until later, 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) #