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 <kai...@ak.jp.nec.com>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
