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 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.
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 <kai...@ak.jp.nec.com>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
