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