KaiGai Kohei wrote:
> I updated the series of patches for SE-PostgreSQL 8.4devel.
>
> [1/5] http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1043.patch
> [2/5] http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1043.patch
> [3/5] http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r1043.patch
> [4/5] http://sepgsql.googlecode.com/files/sepostgresql-docs-8.4devel-3-r1043.patch
> [5/5] http://sepgsql.googlecode.com/files/sepostgresql-tests-8.4devel-3-r1043.patch
I looked over the patches listed above. They have line counts listed
below:
10759 sepostgresql-sepgsql-8.4devel-3-r1043.patch 616 sepostgresql-pg_dump-8.4devel-3-r1043.patch 826
sepostgresql-policy-8.4devel-3-r1043.patch 1237 sepostgresql-docs-8.4devel-3-r1043.patch 836
sepostgresql-tests-8.4devel-3-r1043.patch 14274 total
Particularly interesting was the doc patch,
sepostgresql-docs-8.4devel-3-r1043.patch. It explains how SE-PostgreSQL
checks the permission level of the client process (getpeercon) and uses
that to determine what the user should see. Also interesting is how a
new row-level system permission column references a new table
'pg_security', which holds security credentials for the row.
The bulk of the patch is in sepostgresql-sepgsql-8.4devel-3-r1043.patch,
which modifies the backend. About 30% of it or 3k lines modify our
backend, and the rest are indepdendent support routines in their own C
files.
So, I am now reevaluating how we should proceed with this patch.
I think we know we want column-level permissions and that is being
worked on, so it should reduce the size of the 3k part of that patch
slightly.
As far as backend changes the largest part is the row-level permissions.
Do we want row-level permissions to be accessible at the SQL level,
perhaps optionally, by having a role be associated with a row, and only
role members can see it. If we do, and implement it, the 3k part is
reduced significantly.
FYI, SE-PostgreSQL sets _row_ permissions by assigning to the new
permissions system column:
INSERT INTO drink (security_context, id, name, price)VALUES('system_u:object_r:sepgsql_table_t:SystemHigh', 7, 'tea',
130); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
That string is what is placed in 'pg_security' and a reference to is
placed on the row.
The other conclusion I came to is that the other 11k of patch is really
independent SE-Linux interface code and not likely to change in size no
matter what we implement at the SQL level.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +