Reminding folks this bug is still open.
---
Tom Lane wrote:
> ... because nowhere does it update the "checkAsUser" fields in the
> view's query to be the OID of the new owner. This means that
> permission checks about wheth
Bruce Momjian writes:
> Has this been completed?
No, still on the to-do list. IIRC that was about the time we got
diverted by fixing the encoding security issues...
regards, tom lane
---(end of broadcast)---
TIP 2: Don't '
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> On Sun, Apr 30, 2006 at 12:34:42PM -0400, Tom Lane wrote:
> > 2. Run setRuleCheckAsUser during rule load rather than rule store.
> >
> > #2 is a lot simpler, and would fix the problem for existing broken rules
> > whereas #1 would not
Agreed, RULE permissions seem to be of limited usefulness.
---
Tom Lane wrote:
> Martijn van Oosterhout writes:
> > On Sun, Apr 30, 2006 at 12:34:42PM -0400, Tom Lane wrote:
> >> 2. Run setRuleCheckAsUser during rule load r
Martijn van Oosterhout writes:
> On Sun, Apr 30, 2006 at 12:34:42PM -0400, Tom Lane wrote:
>> 2. Run setRuleCheckAsUser during rule load rather than rule store.
> FWIW, I think #2 is better also.
Actually, I'm sitting here realizing the problem is more complicated
than I thought :-(. The spanne
On Sun, Apr 30, 2006 at 12:34:42PM -0400, Tom Lane wrote:
> 2. Run setRuleCheckAsUser during rule load rather than rule store.
>
> #2 is a lot simpler, and would fix the problem for existing broken rules
> whereas #1 would not, so I'm kind of inclined to go with that. I doubt
> there'd be any mea
... because nowhere does it update the "checkAsUser" fields in the
view's query to be the OID of the new owner. This means that
permission checks about whether the view can access its underlying
tables will still be done as the old owner. An example:
regression=# create user u1;
CREATE ROLE
regr
