On Mon, Dec 14, 2009 at 7:30 AM, KaiGai Kohei <kai...@kaigai.gr.jp> wrote: > (2009/12/14 20:48), Robert Haas wrote: >> >> 2009/12/14 KaiGai Kohei<kai...@ak.jp.nec.com>: >>> >>> Robert Haas wrote: >>>> >>>> 2009/12/13 KaiGai Kohei<kai...@ak.jp.nec.com>: >>>>>> >>>>>> Just to name a few really obvious problems (I only looked at the >>>>>> 01-database patch): >>>>>> >>>>>> 1. We have been talking for several days about the need to make the >>>>>> initial patch in this area strictly a code cleanup patch. Is this >>>>>> cleaner than the code that it is replacing? Is it even making an >>>>>> attempt to conform to that mandate? >>>>> >>>>> Even if it is unclear whether the current form is more clear than the >>>>> current inlined pg_xxx_aclcheck() form, or not, it will obviously >>>>> provide a set of common entry points for upcoming enhanced security >>>>> providers. >>>>> Eventually, it is more clear than enumeration of #ifdef ... #endif >>>>> blocks for SELinux, Smack, Solaris-TX and others. >>>> >>>> Right, but it will also not get committed. :-( >>> >>> The framework will be necessary to get them committed. >>> Which is an egg, and which is a chicken? :-( >> >> We've been around that path a few times, but that's not my point here. >> Doing the framework first makes a lot of sense; the problem is that >> we just had a design discussion regarding that framework and you've >> chosen to do something other than what was discussed. Did you not >> read that discussion? Did you not understand it? > > Please point out, if my understanding is incorrect from the discussion > in a few days. > > * As a draft of the discussion, I have to split out the access control > reworks patch in the 2nd CF per object classes. > * This framework supports only the default PG privileges at the moment. > * The way to host enhanced security providers are not decided. > (Maybe #ifdef ... #endif block, Maybe function pointer) > * It is not decided how many security labels are assigned on a database > object. (Maybe 1:1, Maybe 1:n) > > I don't intend to go to something undecided, but, might understand > something incorrectly or not be able to follow the discussion enough.
Hmm... all of those things are true, but it seems to leave quite a bit out. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers