Re: [HACKERS] Running pgindent

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: jwieck(at)debis(dot)com
Cc: vadim(at)sable(dot)krasnoyarsk(dot)su, hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Running pgindent
Date: 1998-02-20 19:12:46
Message-ID: 199802201912.OAA06951@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)candle(dot)pha(dot)pa(dot)us

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1998-02-20 19:15:09 Re: AW: [HACKERS] triggers, views and rules (not instead)
Previous Message Jan Wieck 1998-02-20 19:06:31 Backend crashes - what's going on here???