Re: How to get SE-PostgreSQL acceptable - Mailing list pgsql-hackers

>>> I think what people
>>> are looking for, instead, is either additional columns to just the
>>> existing system tables that need them (eg: pg_class, pg_attribute) or
>>> included in the existing ACL structure (the aclitem structure).  Another
>>> option might be a seperate set of tables.
>> It should not be held in text form within each tuples.
>> Please remind why I rework for the feature again.
>> Its facilities are a bit large to get included at a time,
>> so its development should be done step-by-step approach and
>> separatable ones (row-level, largeobjects) are postponed.
>> This change is extreamly large, almost same as implementing
>> from zero. I think it is far from step-by-step.
> 
> Yes, the development should be step-by-step, with minimally invasive
> changes each time.  The first step is just hooking into SELinux for
> access levels that PostgreSQL already supports (database, schema,
> table, column).  Requiring that the HeapTupleHeader be changed and that
> additional internal system columns be added, along with SELinux checks
> at levels that aren't appropriate, is alot more than this first patch
> should really need.  Those kinds of changes would be with the patch to
> add non-SELinux row-level security.  Following that, SELinux hooks would
> be added to the RLS checks.

A concetn is current implementation assumes objects to be checked
(tables, columns, ..., now) have its security identifier. Whole of
the access control facility makes its decision based on security
identifier.
When the text form is used? It is used only when SE-PostgreSQL
communicate with in-kernel SELinux because it is protocol.
The result of decision making is cached in userspace to reduce
kernel invocation, and all the entries are tagged by security
identifier. So, any other facility does not need to handle
text form. Removing security id also means replacement of whole
of the current SE-PostgreSQL facilities!

BTW, I had tried an approach which have security label by text,
but its performance pain (due to string comparison) is unacceptable.
(IIRC, about 50% of transaction per sec by pg_bench.)
Indeed, we don't apply MAC on row-level in v8.4, so it does not
make serious matter on table/column level, but is surely has to
be scrapped once and implementaed from zero again.

> I think you need to look at it from the point of view of the committers
> and consider the whole patch, not just the quantity of code under
> security/.  While that is important, the changes to the code *outside*
> of security/ is what the committers are going to be most concerned about
> because that gets into the overall structure and design and are areas
> which are much more likely to affect users who don't use this feature,
> performance, etc.

IIRC, we recently discussed that we should not afraid to apply
core code if it tries to get merged, so, I scraped all the
"PGACE" facilities.
Keeping independency under "security/*" is a concept of PGACE.
It enabled to implement a new security feature with minimum
impact to the core code, but, we concluded it is not necessary
a few days ago, then it is just before to finish most of works...

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