Re: [HACKERS] Running pgindent

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