[PATCH] SE-PgSQL/lite (r2429)

The attached patch is a "lite" version of SE-PostgreSQL,
for the CommitFest#3.

Its characteristic changes from the previous patches are
developer documentations and slimed-up code.

The developer documentation is a suggestion on the last
commit fest. In the CF#2, we worked to implement a common
abstraction layer for both of DAC and MAC, but its change
set got larger than we expected at the begining.
Then, we decided to implement them with deployment of hooks
on the strategic points with clear documentation.

The src/backend/security/sepgsql/README is a documentation
from the viewpoint of developers. I belive it can help to
understand intention of the SE-PgSQL design.
In addition, I paid much efforts to write source code comments
to introduce the purpose and its requirement.

See the:
http://code.google.com/p/sepgsql/source/browse/trunk/sepgsql/src/backend/security/sepgsql/README

The scale of change set has been a headache for us.
Some quantity of change set is unavoidable to implement access
controls on comprehensive database objects.
For example, the catalog/aclchk.c and utils/adt/acl.c have more
than 9,000 lines in total.

In the v8.4 development cycle, I got a suggestion to reduce
a burden of reviewer to split off a few functionalities, such
as "security_context" system column and row-level access controls.

In this patch, I splited off a few functionalities furthermore.
It does not apply any access controls except for four types of
database objects classes; databases, schemas, tables and columns.
We can incrementally implement access controls on the rest of
database objects, such as procedures, in the future.

In addition, I also splited off a few features.
Now it has no special feature to manage security context. It is
stored within a certain text field of system catalogs related to
the four object types.
Now it has no access control decision cache which contributes
abour 800 lines of code reduction.

In total, this patch contains about 9.5KL of change set.
- About 2.1KL for documentaions (doc/src/sgml/* and the README).
- About 1.7KL for test cases (src/test/*).
- Rest of 5.5KL are as follows:
- About 3.3KL for SE-PgSQL specific code with comments.
(include/security/* and backend/security/*)
- About 0.6KL for headers.
- About 1.2KL for core routines.
- About 0.3KL for pg_dump and initdb (bin/*)

You might feel the 3.3KL is still a bit large. But its reason is
obvious in the source code. I paid much efforts to describe source
code comments to help understand the purpose and intention of the
functions.

About half of the 1.2KL is due to the statement support to give
an explicit security context on CREATE or ALTER statement.
But these are commonly-used code, implemented such as:

rel = heap_open(RelationRelationId, RowExclusiveLock);
:
value[Anum_pg_class_relsecon - 1] = CStringGetTextDatum(relsecon);
:
simple_heap_update(rel, &newtuple->t_self, newtuple);
:
heap_close(rel);

I don't think it is a major hurdle for reviewing.
So, all we need to pay great attention is the rest of 0.6KL.
I think it is enough small change set as long as SE-PgSQL does not
lose its soul.

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