Re: How to get SE-PostgreSQL acceptable

Bruce Momjian wrote:
> Robert Haas wrote:
>>>> IANAC, but that's my impression too.  The simplified patch shouldn't
>>>> assume that row-level security in its current form is going to end up
>>>> getting put back in.  AFAICS, there's no reason why the security ID
>>>> for tables can't be a regular attribute in pg_class, or why the
>>>> security attribute for columns can't be a regular attribute in
>>>> pg_attribute.
>>> If it is "identifier", it can be compoundable.
>>>
>>> I dislike it is held as "text". It fundamentaly breaks SE-PostgreSQL's
>>> architecture, and requires to scrap near future.
>> I think the column in pg_attribute and pg_class can and should be an
>> OID.  The issue is whether it's a regular OID column or a new system
>> column.  Stephen and I are saying it should be a regular column.
>> pg_security can stick around to map OIDs to text labels.
> 
> Why an OID?  We store acl items now without a lookup table;  I think
> there will be at most the same number of SE-Linux entries.  Also, by
> using text we avoid the problem of cleaning out unreferenced pg_security
> rows, improve performance (no lookups), and simplify the code.

The reason why I concern about text formed security context is
it has variable length, so it requires to deform/form a HeapTuple
again when SE-PostgreSQL assigns a default security context.
If a user inserts a new tuple into pg_xxxx without explicit security
context, it has to be labeled based on security context. We cannot
estimate what string will be given prior to ExecInsert(), it needs
to put a security label on the given HeapTuple.
If is is a fixed length variable (like "oid"), it is not necessary
to deform/form them. So, I prefer the security identifier.

In addition, it also has performance gain.
The current architecture does not need to look up pg_security in most
cases. SE-PostgreSQL caches results of access controls in userspace
to reduce the number of kernel invocation.
(In generally, context switch is a heavy one.)
All cached entries are tagged by its security identifier, so we can
lookup the entry without string comparing. The text form is used
only when it could not find the entry on the cache. In this case,
SE-PostgreSQL translate security identifier into text form and
ask for in-kernel SELinux. It requires a text form due to the
protocol.

At least, we cannot apply this scheme on the next phase (row-level)
due to the storage consumption and others. So, I don't think it is
a preferable way to design the first step without ignoring upcoming
expandability.

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