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 don't deny two different security mechanisms have same granuality.
It is a choice by its architect, and it can have same or different
guranuality.
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.
Yes, I also agree your opinion.
SE-PostgreSQL is designed to achieve several targets in same time:
- Collaboration with operating system
- Mandatoty access control
- Fine-grained access control
If someone want the last feature only, SE-PostgreSQL provides too much
for him. However, it is designed to replace security mechanism easily.
Have you heared the PGACE security framework?
It is designed by reference to LSM, and provides several hooks to invoke
security mechanism. It checks whether the given query is legal, or not.
In my second option, I will try to implement similar functionality which
provides "fine-grained-only" on PGACE security framework.
However, every security mechanism has horizontal relationship, not a hierarchy,
not a dependency. So, we can make progress in parallel.
(And, they can have individual guranuality and so on.)
Therefore, I think that nonexistence of "fine-grained-only" mechanism should
not block other mechanism to join development cycle.
If it is really really necessary, I try to pay effort to implement the 2nd
option due to the CommitFest:Nov.
But, in my ideal, I want to concentrate to merge SE-PostgreSQL during v8.4
development cycle.
And, I understood there are folks who want only "fine-grained-only" one.
If possible, I want to design and implement it for v8.5 development cycle
with enough days.
Unfortunatelly, remained days are a bit short...
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
