Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)

KaiGai Kohei wrote:
> 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.

Agreed.  I think if the community wants too many features we will not
get this done in time for 8.4.

> 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.

Ah, so you found a way so the column can be optionally used and does not
have to be specified for the entire table using a CREATE TABLE option? 
Great.

> > 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.

Well, having relid allows us to use a smaller int2 and allows us to more
easily remove pg_security rows that are no longer referenced in the user
table.  It is just an idea.

Perhaps the idea of two security columns is too much and we should
consider that in a later release if we find we need it.  Shipping 8.4
with only one active security mechanism at a time is certainly
acceptable and wise, or we might get nothing in 8.4.
> 
> > 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 its oid as the security
>      identifier of given tuple.
>      (pg_security.oid is primary key.)
>   3. When the finding text is not found, it insert a new tuple into
>      pg_security, and put its oid as the security identifier of given tuple.

Nice, I did not realize you had coded that already.  Good approach.

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

OK, good.

> > 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?

Does a table use storage for the security column if no SQL-level
security value is supplied for a given row?

Also what patch version should I be looking at.  How will that version
need to be changed?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +