(2009/12/12 21:51), Robert Haas wrote:
2009/12/12 KaiGai Kohei<kai...@kaigai.gr.jp>:
I'd like to summary about the framework.
I am not necessarily in agreement with many of the points listed in
this email.
* Functionalities
The ACE framework hosts both of the default PG checks and upcoming
enhanced securities. We can build a binary with multiple enhanced
security features, but user can choose one from them at most due
to the security label management.
Just yesterday, Stephen Frost and I were discussing whether to stick a
layer of interdirection into the proposed interface layer using
function pointers. We agreed to defer that decision to a later date.
If, however, we eventually decide to do that, it will clearly mean
that multiple security frameworks are possible simultaneously and that
they can be implemented as loadable modules. On the other hand, we
might decide that that design does NOT make sense, in which case we
might end up with something more like the code snippet you proposed
below, although I'm not sure you have the details right.
I don't intend to include #ifdef ... #endif block in the patches which
I'll submit in the next week. OK, it can be decided later.
My opinion is enhanced security provider should be inlined.
We have also not decided whether to support a single security label or
multiple security labels per object. I tend to think that the case
for multiple labels is pretty thin, but on the other hand it's not
unmangeably difficult to do so. It could be coded up using an array
representation, just as we now do for reloptions. Again, I want to
defer this decision until later. Right now, I want to focus on seeing
whether it is all possible for us to get community buy-in on just
centralizing the existing checks, without making any commitment to
what may come after that.
OK, it to be later.
* Namespace
The framework is stored in the src/backend/security/ace.
As a general rule, Each source file has this naming convension:
src/backend/security/ace/<object_class>_ace.c
Maybe. Generally I think if there's a common prefix it should go at
the beginning of the filename, not the end, but I don't want to get
into source code organization too much at this point. It's too early
to make those decisions.
But we have to deploy source code somewhere. :(
At the moment, "e" of "ace" might not necessary, but it is not productive
to review a patch to replace all the "ac_" by "ace_" later.
So, I'll use this name just as a name at the moment.
* Documentation
I don't plan to provide SGML documentation about ACE itself, except for
internal section, because it is an internal infrastructure.
For developers, src/backend/security/ace/README will provide a brief
overview of the ACE framework, and every security hooks have source
code comments to introduce the specification of itself.
That's probably about right, but I don't want to prejudge that without
further discussion in the community.
If something are necessary, I'll also describe SGML documentation later.
At this moment, I'll include README and source code comments in the
first patches in the next week.
* Patches
As a general rule, a patch is organized for each object classes, except
for very tiny object classes.
e.g)
pgsql-ace-02-database.patch
pgsql-ace-03-schema.patch
:
I'll try to submit a set of patches related to the following object classes
and functionalities by the 12/16.
Stephen Frost is working on a patch for just one object type. I think
that is a better approach than writing code for everything and then
trying to review it all at once. We need to try to get consensus on
the basic design before we write a lot of code. I do agree however
that **if** we are able to get consensus on one object type, we should
probably design the whole thing as a stack of patches that apply on
top of each other, one per object type, for easier review. That's not
an approach I usually favor, but in this case I think it makes sense.
What I wanted to say is that about a dozen of patches at once are not
happy for us, so I'd like to submit a limited number of patches earlier.
Are you saying that I should submit one-by-one and more rapidly?
I don't have any reason to oppose it.
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
