Re: How to get SE-PostgreSQL acceptable - Mailing list pgsql-hackers

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@kaigai.gr.jp>