Re: [HACKERS] Reimplementing permission checks for rules

2000-09-28 Thread Peter Eisentraut
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

Re: [HACKERS] Reimplementing permission checks for rules

2000-09-27 Thread Tom Lane
Peter Eisentraut <[EMAIL PROTECTED]> 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

Re: [HACKERS] Reimplementing permission checks for rules

2000-09-27 Thread Peter Eisentraut
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 st

Re: [HACKERS] Reimplementing permission checks for rules

2000-09-27 Thread Peter Eisentraut
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 ze

Re: [HACKERS] Reimplementing permission checks for rules

2000-09-26 Thread Philip Warner
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 pro