Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)

Is there any reason it's easier to do as a configure option instead of
an initdb option or better yet a per-database option?

The reason we're shying away from configure options for functionality
changes is that more and more users are getting pistgres from binary
distributions. Which option should redhat ship for example?

Also, a configure option is kind if weird since that's a property of
the binary not the data: what happens if you build a database with
selinux and the switch binaries to a non-we build? Is that option in
pg_control?

--
Greg

On 10 Dec 2008, at 12:13, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp> wrote:

> Bruce Momjian wrote:
>> Tom Lane wrote:
>>> KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> writes:
>>>> Bruce Momjian wrote:
>>>>> I assume that could just be always enabled.
>>>> It is not "always" enabled. When we build it with SE-PostgreSQL
>>>> feature,
>>>> rest of enhanced security features (includes the row-level ACL) are
>>>> disabled automatically, as we discussed before.
>>> It seems like a pretty awful idea to have enabling sepostgres take
>>> away
>>> a feature that exists in the default build.
>> Agreed.
>
> I don't agree. What is the reason why? It has been unclear for me.
>
> The PGACE security framework is designed to allow users to choose
> an enhanced security mechanism from some of provided options.
> (Currently, we have sepgsql and rowacl.)
> It is quite natural that one is disabled when the other is enabled.
>
> If a specific enhanced security mechanism has a privileged position,
> it should not be a guest of the security framwork, and be hardcoded
> like existing table-level database ACLs.
>
> Again, I don't oppose the Row-level ACLs to be the default selection.
> However, it should be a selectable option.
>
> Thanks,
>
>> The problem is that the security column used for SQL-level row
>> security is reused to hold the SE-Linux ACL when SE-Linux is
>> enabled. I
>> suppose the only way to enable them both in an SE-Linux build would
>> be
>> to use a new optional column for SE-Linux and keep the SQL-level row
>> security optional column unchanged.
> --
> KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers