Tom Lane wrote: > KaiGai Kohei <[EMAIL PROTECTED]> writes: >> Tom Lane wrote: >>> Yeah, I remember those. What needs to be looked at here is *why* the >>> output is changing. For a patch that allegedly does not touch the >>> planner, it's fairly disturbing that you don't get the same results. > >> SE-PostgreSQL does not touch the planner, but it modifies given query >> to filter violated tuples for the current user. > > Hmm. Is that really a good idea, compared to hard-wiring the checks > into nodeSeqscan and friends? I didn't look at the query-rewriting > portion of the patch in any detail, but I'd tend not to trust suchte > a technique very far: getting it right is going to be quite complex > and probably bug prone.
In the prior base version (8.2.x and 8.3.x), I tended to implement these stuffs in the modular part as far as possible, because massive patched hanks makes more difficult to follow the mainstreamed PostgreSQL. :-( However, the hard-wides checks look like a good idea for me. I tried to implement a prototype of the disign, and currently it works fine. If we can replace the implementation of tuple-level access controls by this design, it makes the implementation simpler. Now, I add a hook into ExecScan(). It can return true or false, to decide whether a given tuple is filtered or not. Permissions to be evaluated are delivered via Scan structure. A variable named as pgaceTuplePerms (uint32) is added to keep permission set for tuple level access controls into Scan structure. If the security module put a proper bitmask on pgaceTuplePerms of RangeTblEntry, it is copied to related Scan structure later. >>> Are you sure that the security_label type should not have an array type? > >> Yes, security_label type should not have an array type. > > You didn't provide one ounce of justification for making it not obey the > expected behavior, so I'm not accepting this position. It doesn't seem > to me to be all that unlikely that users would want to compute with > arrays of security labels. As an example: > select ... where security_label in ('foo', 'bar') > which will become an = ANY(ARRAY[]) construct under the hood. Ah.., I didn't intend such kind of usage, so security_label type does not have operators to use it directly, not only array support. I'll add it in the next patch set. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <[EMAIL PROTECTED]> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers