Re: [0/4] Proposal of SE-PostgreSQL patches

From: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
Subject: Re: [0/4] Proposal of SE-PostgreSQL patches
Date: 2008-05-12 07:18:54
Message-ID: 4827EF5E.3060607@ak.jp.nec.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Tom Lane wrote:
> KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)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(at)ak(dot)jp(dot)nec(dot)com>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2008-05-12 08:35:05 pgsql: Convert wal_sync_method to guc enum.
Previous Message Hans-Juergen Schoenig 2008-05-12 07:05:54 Re: XIDs and big boxes again ...

Browse pgsql-patches by date

  From Date Subject
Next Message Pavel Stehule 2008-05-12 07:29:56 Re: options for RAISE statement
Previous Message Tom Lane 2008-05-12 03:48:29 Re: Making sure \timing is on