Re: Updates of SE-PostgreSQL 8.4devel patches (r1197) - Mailing list pgsql-hackers

Simon Riggs wrote:
> On Thu, 2008-11-13 at 10:44 +0900, KaiGai Kohei wrote:
> 
>> It's unclear for me what is the point you said.
>> I guess you concern the fixed length field is always allocated in
>> the case when any security feature is not enabled also, or performance
>> degradation on the large scale databases.
>> If incorrect, please tell me in another expression.
>>
>> At first, the fixed length 4 byte field is allocated only when
>> the SE-PostgreSQL (or other security feature) is enabled. It can be
>> controlled via PGACE hook. The pgaceSecurityAttributeNecessary() can
>> return bool value, and it indicates the necessity of the security
>> field. If SE-PostgreSQL is disabled on compile-time or run-time,
>> the fixed length 4 byte value is not allocated.
> 
> I'm sorry for not making my thoughts clearer. Let me try again:
> 
> As I understand it, when enabled, the overhead for each row is more than
> 4 bytes because you include a text field also, which you say has a
> restricted number of values. IMHO the overhead is unacceptable, given
> that our row overhead is already high. I would prefer to make the
> maximum overhead per row 4 bytes only, which matches the maximum number
> of required labels. This will allow very large databases to use this
> feature.

Indeed, the additional storage comsumption is not just only fixed 4 bytes
per tuple, because these security identifiers require its text representation.
However, the rate of them are nearly zero in very large databases, especially.

Please consider the following example:

postgres=# SELECT security_context, * FROM t1;             security_context               | a |  b
---------------------------------------------+---+-----unconfined_u:object_r:sepgsql_table_t:s0    | 1 |
aaaunconfined_u:object_r:sepgsql_table_t:s0   | 2 | bbbunconfined_u:object_r:sepgsql_table_t:s0    | 3 |
cccunconfined_u:object_r:sepgsql_table_t:s0:c0| 4 | dddunconfined_u:object_r:sepgsql_table_t:s0:c0 | 5 |
eeeunconfined_u:object_r:sepgsql_table_t:s0:c1| 6 | fffunconfined_u:object_r:sepgsql_table_t:s0:c1 | 7 |
gggunconfined_u:object_r:sepgsql_table_t:s0:c2| 8 | hhh
 
(8 rows)

postgres=# SELECT oid, * FROM pg_security; oid  |                  seclabel
-------+--------------------------------------------- 3397 | unconfined_u:object_r:sepgsql_table_t:s0 3398 |
unconfined_u:object_r:sepgsql_proc_t:s03399 | unconfined_u:object_r:sepgsql_db_t:s016390 |
unconfined_u:object_r:sepgsql_table_t:s0:c016391| unconfined_u:object_r:sepgsql_table_t:s0:c116392 |
unconfined_u:object_r:sepgsql_table_t:s0:c2
(6 rows)

The table "t1" contains eight tuples, and there are four kind of security context.
Every tuples has fixed 4-bytes identifier to indicate oid of pg_security which
contains text representation.
(Its output handler translate it into human readable text form.)
The first three tuples have "3397" as its security identifier which indicates
the tuple of "unconfined_u:object_r:sepgsql_table_t:s0" within pg_security.
This entry is shared by them.

If a table has 1,000,000 of tuples labeled by 100 kind of security contexts,
we only need 100 tuples on the pg_security system catalog. In this case, the sum
of text representation length is 5,000 byte at maximum, it is small enough.

In other word, the relationship between a security identifier and an entry of
pg_security is n:1, not 1:1.
Sorry, it seems to me you misunderstand something.


> I would also like to see the feature part of normal Postgres, rather
> than as a compile time option. The per-row overhead would then be
> optional, just as WITH OIDS is optional. This would allow many
> applications to take advantage of row level security, without the need
> for switching to a different executable and without the need to enable
> it for every table. For high security applications, default_row_security
> = on would obviously be a requirement. With a single executable on all
> distros we will have more robust software and it will be easier to
> configure and use.

An issue is who can enable or disable the row-level security option.
If the owner of table can do it discretionary, we don't call it a
"mandatory" access control feature.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>