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 <kai...@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
