Re: [0/4] Proposal of SE-PostgreSQL patches - Mailing list pgsql-hackers

Tom Lane wrote:
> KaiGai Kohei <kaigai@ak.jp.nec.com> writes:
>> Some of the test fails contains minor differences from expected results, like:
> 
>> |   SELECT '' AS "xxx", *
>> |     FROM J1_TBL t1 (a, b, c) NATURAL JOIN J2_TBL t2 (d, a);
>> |    xxx | a | b |  c   | d
>> |   -----+---+---+------+---
>> |  -     | 0 |   | zero |
>> |        | 2 | 3 | two  | 2
>> |        | 4 | 1 | four | 2
>> |  +     | 0 |   | zero |
>> |   (3 rows)
> 
> 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.
Thus, the above query is dealt as if the following query is inputed.

SELECT '' AS "xxx", * FROM J1_TBL t1 (a, b, c) NATURAL JOIN J2_TBL t2 (d, a) ON
sepgsql_tuple_perms(t1.security_context,SEPGSQL_PERMS_SELECT, ...)    and sepgsql_tuple_perms(t2.security_context,
SEPGSQL_PERMS_SELECT,...);
 

sepgsql_tuple_perms() returns true, if the security policy allows user
to access a given tuple. It returns false, if not so.

The result of EXPLAIN shows it more clearly:

| kaigai=# EXPLAIN SELECT '' AS "xxx", * FROM J1_TBL t1 (a, b, c) NATURAL JOIN J2_TBL t2 (d, a);
|                                           QUERY PLAN
| -----------------------------------------------------------------------------------------------
|  Hash Join  (cost=29023.54..82599.93 rows=1380 width=44)
|    Hash Cond: (t2.a = t1.a)
|    ->  Seq Scan on j2_tbl t2  (cost=0.00..53526.05 rows=713 width=8)
|          Filter: pg_catalog.sepgsql_tuple_perms(tableoid, security_context, 12288, t2.*)
|    ->  Hash  (cost=29018.70..29018.70 rows=387 width=40)
|          ->  Seq Scan on j1_tbl t1  (cost=0.00..29018.70 rows=387 width=40)
|                Filter: pg_catalog.sepgsql_tuple_perms(tableoid, security_context, 12288, t1.*)
| (7 rows)

>> and, some of them are trivial ones, like:
> 
>> |   SELECT p1.oid, p1.typname
>> |   FROM pg_type as p1
>> |   WHERE p1.typtype in ('b','e') AND p1.typname NOT LIKE E'\\_%' AND NOT EXISTS
>> |       (SELECT 1 FROM pg_type as p2
>> |        WHERE p2.typname = ('_' || p1.typname)::name AND
>> |              p2.typelem = p1.oid and p1.typarray = p2.oid);
>> |  - oid | typname
>> |  ------+---------
>> |  - 210 | smgr
>> |  - 705 | unknown
>> |  -(2 rows)
>> |  + oid  |    typname
>> |  +------+----------------
>> |  +  210 | smgr
>> |  +  705 | unknown
>> |  + 3403 | security_label
>> |  +(3 rows)
> 
> Are you sure that the security_label type should not have an array type?
> I do not offhand see a good argument for that.  If it really shouldn't,
> we can change the expected output here, but you've got to make that
> case first.

Yes, security_label type should not have an array type.
It is defined with typelem=0 and typarray=0.
The purpose of this type is to represent the new system column of
security attribute ("security_context" column).

So, I think it is a case that a new expented output should be modified.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>