Re: How to get SE-PostgreSQL acceptable

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/Column level 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 to check 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
- Writable system column
Because Row-level one is postponed, we don't need to export/import
security_label of tuples to/from users 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(at)ak(dot)jp(dot)nec(dot)com>