I'm thinking about changing the way that access permission checks are
handled for rules.  The rule mechanism provides that accesses to tables
that are mentioned within rules are done with the permissions of the
rule owner, not the invoking user.  The way this is implemented is that
when a rule is substituted into a query, the rule rewriter
  (a) does its own permission checking on the newly-added rangetable
      entries, and
  (b) sets a "skipAcl" flag in each such RTE to prevent the executor
      from doing normal permissions checking on that RTE.

This is pretty ugly.  For one thing, it means near-duplicate code that
has to be kept in sync between the executor and the rewriter.  For
another, it's not good that rule-related permissions checks happen at
rewrite time instead of execution time.  That means that a cached
execution plan will not respond to later changes in table permissions,
if the access comes via a rule rather than a direct reference.

What I'm thinking about doing is eliminating the "skipAcl" RTE field
and instead adding an Oid field named something like "checkAclAs".
The semantics of this field would be "if zero, check access permissions
for this table using the current effective userID; but if not zero,
check access permissions as if you are this userID".  Then the rule
rewriter would do no access permission checks of its own, but would
set this field appropriately in RTEs that it adds to queries.  All the
actual permissions checking would happen in one place in the executor.

Comments?  Is this a general enough mechanism, and does it fit well
with the various setUID tricks that people are thinking about?

			regards, tom lane

Tue, 26 Sep 2000 10:54:10 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Reimplementing permission checks for rules
At 10:54 26/09/00 -0400, Tom Lane wrote:
>
>Comments?  Is this a general enough mechanism, and does it fit well
>with the various setUID tricks that people are thinking about?
>

Didn't Peter & Jan have a rewrite of the permissions system in the pipeline
- or has that disappeared? What Jan was proposing was rather more
substantial than just the setuid stuff, I *think*.




----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|
                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/

Wed, 27 Sep 2000 02:13:24 +1000
Philip Warner <pjw@rhyme.com.au>
Re: Reimplementing permission checks for rules
Tom Lane writes:

> What I'm thinking about doing is eliminating the "skipAcl" RTE field
> and instead adding an Oid field named something like "checkAclAs".
> The semantics of this field would be "if zero, check access permissions
> for this table using the current effective userID; but if not zero,
> check access permissions as if you are this userID".  Then the rule
> rewriter would do no access permission checks of its own, but would
> set this field appropriately in RTEs that it adds to queries.  All the
> actual permissions checking would happen in one place in the executor.

I like it.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/


Wed, 27 Sep 2000 12:41:52 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Reimplementing permission checks for rules
Philip Warner writes:

> Didn't Peter & Jan have a rewrite of the permissions system in the pipeline
> - or has that disappeared? What Jan was proposing was rather more
> substantial than just the setuid stuff, I *think*.

If I had known that we wouldn't beta until October I probably would have
started on it.  But there's a technical incompatibility issue at the core
of my idea that would have forced a postpone until 7.2 for some parts
anyway.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/


Wed, 27 Sep 2000 12:42:15 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Reimplementing permission checks for rules
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> What I'm thinking about doing is eliminating the "skipAcl" RTE field
>> and instead adding an Oid field named something like "checkAclAs".
>> The semantics of this field would be "if zero, check access permissions
>> for this table using the current effective userID; but if not zero,
>> check access permissions as if you are this userID".  Then the rule
>> rewriter would do no access permission checks of its own, but would
>> set this field appropriately in RTEs that it adds to queries.  All the
>> actual permissions checking would happen in one place in the executor.

> I like it.

OK.  BTW, what is the status of the changeover you proposed re using
OIDs instead of int4 userids as the unique identifiers for users?
In other words, should my field be type Oid or type int4?

			regards, tom lane

Wed, 27 Sep 2000 10:41:38 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Reimplementing permission checks for rules 
Tom Lane writes:

> OK.  BTW, what is the status of the changeover you proposed re using
> OIDs instead of int4 userids as the unique identifiers for users?

Because of the pg_dumpall thing that had to be postponed for another
release, otherwise the users would be associated to the wrong groups on
restore.

> In other words, should my field be type Oid or type int4?

Interesting question, actually, because the master uid global variable has
always been a Oid type but it was mostly referenced as int4.  Considering
that we have a whole oid/int4 mess and that you can't have negative uid's
anyway, you might as well go for the Oid now if you don't mind.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/


Thu, 28 Sep 2000 10:49:58 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Reimplementing permission checks for rules 