Re: Updates of SE-PostgreSQL 8.4devel patches - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Updates of SE-PostgreSQL 8.4devel patches
Date
Msg-id 200809241929.m8OJTXl08524@momjian.us
Whole thread Raw
In response to Updates of SE-PostgreSQL 8.4devel patches  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Responses Re: Updates of SE-PostgreSQL 8.4devel patches  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
List pgsql-hackers
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. +


pgsql-hackers by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: parallel pg_restore
Next
From: Heikki Linnakangas
Date:
Subject: Re: pgsql: Make LC_COLLATE and LC_CTYPE database-level settings.