A.M. wrote:
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.
I understand what you say is the part of decision making should be
pluggable and like a "fine-grained-only" mode should be selectable.
(I'm sorry, if my understanding is incorrect.)
I thought this approach prevents to support various kind of "enhanced"
security mechanism on PGACE security framework.
Do you know SE-PostgreSQL is designed to use common set of security hooks
named as PGACE? It provides bare hooks and minimum facilities to handle
security attribute. The reason why it does not define internal structure
of security mechanism is to avoid to assume specific mechanism.
My preference is to switch whole of security mechanism by configuration
option as SE-PostgreSQL or LSM doing.
Thanks,
--
KaiGai Kohei <[EMAIL PROTECTED]>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
