Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep) - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Date
Msg-id 603c8f070809191042n1945a319uf133f1bd981302e1@mail.gmail.com
Whole thread Raw
In response to Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)  (KaiGai Kohei <kaigai@kaigai.gr.jp>)
Responses Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)  (KaiGai Kohei <kaigai@kaigai.gr.jp>)
Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)  ("A.M." <agentm@themactionfaction.com>)
Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
> 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.

...Robert


pgsql-hackers by date:

Previous
From: KaiGai Kohei
Date:
Subject: Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Next
From: Greg Stark
Date:
Subject: Re: Assert Levels