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

Bruce Momjian wrote:
> We have had discussion on whether we want one or two security columns; 
> there have been comments on both sides.

It is quite natural end-user should be able to choose one of provided
security mechanisms, in my opinion. It means user (administrator) allows
his prefered security mechanism to use security column and security field.

It makes the implementation keep simple, and avoid some of pains.

How frequently does someone want to *work* (not compile) DAC and MAC
in same time? I could not believe it is a generic demand.
I expect that a user who explicitly enables SE-PostgreSQL by hand,
he focuses on MAC feature.

> Have we decided if we are going to use some type of integer on every row
> that points to a pg_security row or put the value right in the row?

The reason why I decided to put an integer value on HeapTupleHeader,
as "oid" doing, is that it has to be modified after simple_heap_insert()
or ExecInsert(). It has to be fixed length and not a user data.

> If we use some type of integer, I suggest using this structure for
> pg_security:
> 
>     CREATE TABLE pg_security(
>         relid oid, 
>         secid int2, 
>         secacl aclitem[], 
>         secext TEXT
>     );
> 
> This allows the per-row value to be a simple int2.  It also improves
> maintenance because rows are associated only with a specific table;
> unused values can then be removed more easily.  And it allows both
> secacl and secext security to be specified.

How does the approach resolve the pain of user interface?
I don't think packing two or more values into one field is not a right way.

> I am unsure how an insert into a 'security_context' column would
> automatically insert into pg_security however.  I am also unclear how
> COPY would work.

When a pgaceHeapTupleInsert() hook is invoked without specific security
context, SE-PostgreSQL does... 1. Compute a default security context. It ask for the security policy,    if necessary.
2.It lookup pg_security via SysCache. If the required text representation    is on the pg_security, SE-PostgreSQL put
itsoid as the security    identifier of given tuple.    (pg_security.oid is primary key.) 3. When the finding text is
notfound, it insert a new tuple into    pg_security, and put its oid as the security identifier of given tuple.
 

COPY statement also invokes heap_insert(), so SE-PostgreSQL assign
a proper security context in same way.

> Also, having the per-row value always be present in the row and
> controlled by the bitmask seems ideal;  it avoids having to add a CREATE
> TABLE option.

Sorry, I don't understand why it related to a CREATE TABLE option.
System columns are always allocated for any tables?

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