Re: [PATCH] ACE Framework - Database, Schema
От | Robert Haas |
---|---|
Тема | Re: [PATCH] ACE Framework - Database, Schema |
Дата | |
Msg-id | 603c8f070912140434m6b7f4ed8p13635421c158c0f4@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] ACE Framework - Database, Schema (KaiGai Kohei <kaigai@kaigai.gr.jp>) |
Ответы |
Re: [PATCH] ACE Framework - Database, Schema
|
Список | pgsql-hackers |
On Mon, Dec 14, 2009 at 7:30 AM, KaiGai Kohei <kaigai@kaigai.gr.jp> wrote: > (2009/12/14 20:48), Robert Haas wrote: >> >> 2009/12/14 KaiGai Kohei<kaigai@ak.jp.nec.com>: >>> >>> Robert Haas wrote: >>>> >>>> 2009/12/13 KaiGai Kohei<kaigai@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
В списке pgsql-hackers по дате отправления: