Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> I don't know, but imho one field for all permissions would have been
> better, like we discussed for the permissions system table, since
> there are more rights in SQL than read/write (e.g. write is separated
> into insert, update and delete)
N
Sorry for the late reply, but I was on vacation (my 2. daughter was born).
> After looking at the rule rewriter some more, I realized that the only
> way to push all permissions checks to execution time is not
> only to keep
> skipAcl, but to generalize it. The problem is with checks on the vie
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
>> What I'm thinking about doing is eliminating the "skipAcl" RTE field
>> and instead adding an Oid field named something like "checkAclAs".
>>
>> Comments? Is this a general enough mechanism, and does it fit well
>> with the various setUID tri
> 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 ac
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
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
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
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
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
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
10 matches
Mail list logo
