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 whether
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, so I'm
Bruce Momjian pgman@candle.pha.pa.us 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
Agreed, RULE permissions seem to be of limited usefulness.
---
Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
On Sun, Apr 30, 2006 at 12:34:42PM -0400, Tom Lane wrote:
2. Run setRuleCheckAsUser during
... 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
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
Martijn van Oosterhout kleptog@svana.org 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
