Re: Updates of SE-PostgreSQL 8.4devel patches

Bruce Momjian wrote:
> KaiGai Kohei wrote:
>> Bruce Momjian wrote:
>>>> > 2) Do we want row-level permissions at the SQL level?
>>>>
>>>> Now I'm working for it and will submit patches due to the end of Oct,
>>>> if it is really required to make progress reviewing of SE-PostgreSQL
>>>> on the v8.4 development cycle.
>>>> However, the scale of its demand is unclear for me.
>>> Yes, which is why I would like the community to answer the question
>>> before you have to start coding things. I will say that if we do want
>>> it, the SE-Linux code will be 96% in separate modules and will make it
>>> much easier to accept.
>> OK, I'll stop my hand today, and wait for pgsql-hacker's opinions.
>
> Here is how I think SQL-level row permissions would work:
>
> We already have an optional OID system column that can be specified
> during table creation (WITH OIDS). We could have another optional oid
> column (WITH ROW SECURITY) called security_context which would store the
> oid of the role that can see the row; if the oid is zero (InvalidOid),
> anyone can see it. SE-PostgreSQL would default to WITH ROW SECURITY and
> use the oid to look up strings in pg_security.

The above explanation is not correct, as Tom mentioned.
The security system column is declared as TEXT type, however, every tuple
has a Oid value to indicate pg_security system catalog. It enables to
prevent waste of storage. When user tries to read the system column,
it is translated from Oid to text representation.

If the oid is zero, SE-PostgreSQL requires SELinux to provide an alternative
security context called as "unlabeled_t". And SE-PostgreSQL checks client's
right for the tuple which is considered as "unlabeled_t".

The part of implementation is specific for SE-PostgreSQL, so another security
mechanism will able to handle InvalidOid as a mark of "no specific checks".

> Is this something we want for non-SE-PostgreSQL builds? SE-PostgreSQL
> would still be a compile-time option because of all the additional
> SE-Linux support code.

The new system column is now enabled only for SE-PostgreSQL builds.
When we don't enables it, the system column is not appeared and it
does not reuire any additional field in HeapTupleHeader.

We provide it as a common facility for "enhanced" security mechanism.
If the guest of PGACE need the security system column, it has to
define "SECURITY_SYSATTR_NAME" in pg_config.h via configure script.
This constant is the key to activate the security system attribute.

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>