Re: How to get SE-PostgreSQL acceptable - Mailing list pgsql-hackers

Obviously, we cannot make clear state of the row-level access
controls by the date of v8.4 freeze.

I agree the row-level access controls can be separated and
postponed to v8.5 development cycle.

So, I'll cut off a few part of previous patches for v8.4.
Stephen Frost gave me a guideline about what should be remained
or postponed *now*. It is SE-PG feature covers granularity
existing PG facility enables to provide.
(Typically, table/column level checks without row level)

* The following features are still included for v8.4 (stage #01) - Centralized SELinux policy and getpeercon(3). -
Table/Columnlevel access controls.   Keep the current behavior.   It checks client's privileges and raises error, if
violated.
 - Functions, Databases   The places to make decision are controversial.   Is pg_xxx_aclcheck() possible to add SELinx
check?  I'll check it later.
 
 - Permission checks on shared library file   The vanilla PG trusts superuser, but MAC don't trust him.   So, we have
tocheck the library's attribute. It should not   be postponed because a malicious library once loaded can do   anything
internally.

* The following features are postponed for v8.5 - Row-level access controls - Binary-large-objects access controls -
Writablesystem column   Because Row-level one is postponed, we don't need to export/import   security_label of tuples
to/fromusers now.
 

* The following features are scraped. - PGACE security framework

As I estimated in the previous message, scale of the main patch
will be 6000-7000 lines. I'll pay my highest efforts to show the
stripped patches within 5 days, due to Feb 04 JST.

Thanks,

| ---- Road Map (My plan) ----
|
| * The stage#1 patches.
V
---- PostgreSQL v8.4 ----
|
| * Platform independent row-level access controls
| * Writable system column (security_label, security_acl).
|   Maybe, we can also discuss writable "oid" in same time.
V
---- First CommitFest ----
|
| * SE-PostgreSQL row-level access controls.
V
---- Second CommitFest ----
|
| * Rest of features like binary large objects.
V
---- Third CommitFest ----
|
:
V
---- PostgreSQL v8.5 ----

Ron Mayer wrote:
> Joshua Brindle wrote:
>> Nonetheless, this conversation seems moot now that Tom has walled off
>> and won't even discuss row-level access controls.
> 
> I think that's a bit of an overstatement.
> 
> He says he's against them[1] and he says that they are the sticking
> point on this patch[2], and that they break SQL[2] and that he believes
> that implementations of row level acls he can imagine would be buggy[2].
> 
> Elsewhere other people on the core team are suggesting that
> others want to see SQL-level row permissions[3].
> 
> 
> My reading of the discussion is that row-level access controls aren't
> vetoed permanently, but rather that (a) it's still clear what SQL
> semantics they'll break, (b) the implementations discussed so far
> seem at high risk of bugs to some people, and (c) some people haven't
> been sold on the need for them.    None of those necessarily state
> that the feature will never get into postgres; but it makes it sound
> like a really high bar to jump over for a release that was originally
> scheduled to be done a while ago.
> 
> [1] http://archives.postgresql.org/pgsql-hackers/2009-01/msg02389.php
> [2] http://archives.postgresql.org/pgsql-hackers/2009-01/msg02339.php
> [3] http://archives.postgresql.org/pgsql-hackers/2009-01/msg02391.php

-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>