Tom Lane wrote:
> "Robert Haas" <robertmhaas@gmail.com> writes:
>>> That's the wrong question. The question here is: does it make sense to
>>> have per-row permissions implemented on top of an abstraction layer
>>> whose sole current implementation is SE-Linux?
>
>> Er, Bruce was asking about per-column, not per-row.
>
>> There's a patch listed on CommitFest:2008-09 to introduce per-column
>> permissions, but it's apparently still WIP. How much does that
>> overlap/conflict with these patches?
>
> Yeah, Stephen Frost is working on that and still has a ways to go.
> I think he might get it done in time for 8.4 (ie, in time for the
> November commitfest) but it's far from certain.
>
> Per-column permissions are part of the SQL standard, and so I think
> we have to implement that without depending on any OS-specific
> infrastructure.
Yes, I agree this position. The OS-specific infrastructure works
orthogonally with native SQL standard access controls, as DAC/MAC
works orthogonally on operating system.
> So on that end I agree with Bruce's position that
> we should do the SQL version first and then think about extensions
> for SELinux.
A proposal of fine-grained security without OS is here:
http://archives.postgresql.org/pgsql-hackers/2008-09/msg01528.php
I'll pay my effort to submit a series of patches due to end of the Oct.
> Per-row is not in the spec and so we can design that as we please.
> But as I mentioned a moment ago, I don't see how it can possibly
> play nice with foreign keys ...
As I noted in above message, it handles PK/FK constraints as follows:
- When a user tries to insert/update a tuple with duplicate PK, it is failed independent from its visibility.
- When a user tries to insert/update a tuple with FK, the refered PK have to be visible.
- When a user tries to update/delete a tuple with PK which is refered by invisible FK, it is failed independent from
itsvisibility.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>
