Thread: Reimplementing permission checks for rules
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
permissionschecking 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
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 |/
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/
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/
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
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/