On Sep 19, 2008, at 1:42 PM, Robert Haas wrote:
>> It's too early to vote. :-)
>>
>> The second and third option have prerequisite.
>> The purpose of them is to match granularity of access controls
>> provided by SE-PostgreSQL and native PostgreSQL. However, I have
>> not seen a clear reason why these different security mechanisms
>> have to have same granuality in access controls.
>
> Have you seen a clear reason why they should NOT have the same
> granularity?
>
> I realize that SELinux has become quite popular and that a lot of
> people use it - but certainly not everyone. There might be some parts
> of the functionality that are not really severable, and if that is the
> case, fine. But I think there should be some consideration of which
> parts can be usefully exposed via SQL and which can't. If the parts
> that can be are independently useful, then I think they should be
> available, but ultimately that's a judgment call and people may come
> to different conclusions.
If the SE-PostgreSQL effort simply implemented SQL interfaces to
increase security granularity, it wouldn't be SE-PostgreSQL at all. SE-
PostgreSQL integrates with a set of optional system-wide access
controls and is only marginally related to SQL-level database
features. Since it relies on an optional component, it doesn't really
make sense that anyone is surprised that the patch doesn't improve
security granularity of vanilla PostgreSQL.
Cheers,
M