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