>> 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 <kaigai@kaigai.gr.jp>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No comments:
Post a Comment