Bruce wrote:
> 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.
Only to copyfuncs.c now. Is it possible that they get
output/reread after deepRewriteQuery()?. I don't think so.
And since makenode() initializes the allocated memory to
nulls aclSkip defaults to false.
> > 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.
Instead of granting users access to pg_rewrite we should use
again some mechanism in rewriteDefine/ExecCheckPerms to let
users only create rules through the CREATE RULE command. Not
by INSERT INTO pg_rewrite. Then we can check during the
creation of a rule that the user is the owner of the relation
the rule is on. Totally safe then.
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) #
