Re: How to get SE-PostgreSQL acceptable

Robert Haas wrote:
> I haven't read the code, but from reading the docs, I have a feeling
> that right now the answer to both questions are NO, which means it
> doesn't really have a lot of value. One example of this is the
> pg_security system catalog. The catalog representation you're
> proposing is probably just fine for associating OIDs to SELinux
> security labels. But trying to present it as a general thing that
> some other security implementation could reuse just doesn't seem
> realistic. Who is to say that the next person who writes an enhanced
> security feature will want to use text as the representation for their
> security domains? It could just as easily be two integers, or an
> array of booleans. This is after all a database product, so the
> chances that someone would want to do something with structured data
> seem non-negligible.

Text represented security attribute is the most common format
for any other security mechanism also.
(For example, T-SOL also have its text representation.)
In addition, TEXT is the most flexible format. If any other
feature want to handle it as an array, it can be stored as
a text representation.

> In the end, you're going to have to be the one who makes the decision
> on which way to go. In some ways, I think that a plugin architecture
> would be better for everyone: we worry about the things on our side of
> the abstraction boundary, and you worry about the things on your side.
> Potentially you or someone else can release enhanced security plugins
> without needing any changes to core, and potentially on a different
> release cycle. On the other hand, a plugin architecture is probably
> going to be a lot of work. It seems that to install the plugin you
> would need to make system catalog changes as well as stuff additional
> system attributes into every table, which are relatively invasive
> changes. And you'll need to convince everyone that it's really a
> plug-in architecture and not just a special case for SE-PostgreSQL, so
> you'll need to prove that there are multiple viable clients, perhaps
> by backporting our existing DAC.

Please make clear the meaning of terms.
The 'plugin' means a loadable module which provides its own security
policy, doesn't it?

There is fundamental difference between built-in and plug-in.
The most important factor is where the hooks are deployed, and
what facility enables to manage security attribute.

Even if I implement SE-PostgreSQL as a loadable module, core
PostgreSQL has to provide proper hooks in strategic points and
facilities to manage security attribute (pg_security system catalog
and security_label system column).
If you require to implement it without these facilities, I think
it is impossible and prefer scraping PGACE and integrate SE- code
into core.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>