Re: security hook on table creation
От | KaiGai Kohei |
---|---|
Тема | Re: security hook on table creation |
Дата | |
Msg-id | 4CB3C0DD.9060804@ak.jp.nec.com обсуждение исходный текст |
Ответ на | Re: security hook on table creation (KaiGai Kohei <kaigai@ak.jp.nec.com>) |
Ответы |
Re: security hook on table creation
(Robert Haas <robertmhaas@gmail.com>)
|
Список | pgsql-hackers |
It seems to me the conclusion of this discussion is unclear. We commonly try to find out an approach that minimize code complexity to understand and maintain, so the point of issue is clear, but we still don't reach same conclusion, because both of two ideas have merits and demerits each other. * Prep/Post-creation hook merits: simple principle to deploy security hooks. The prep-creation hook shall be after existingDAC checks, and the post-creation hook shall be after modification of system catalogs. demerits: several specificsecurity hooks are necessary, in addition to the main security hook. * Only post-creation hook merits: small number of security hook definitions. demerits: at least, new entries of systemcatalog must be visible when we invoke the security hooks, so some cases require us to add new CCIs on invocations,but it requires us to verify it is harmless (whenever we will touch the code around security hooks in thefuture). In my viewpoint, MVCC is one of the most complex things in PG. So, in fact, I also missed the possibility that the gust of security hook cannot reference the entry of new database object, when the idea of post-creation hook was suggested. If we have a strong (and implicit) restriction about places where we should deploy the security hooks on, I don't think it enables to minimize our task to understand and maintain (in the future), although line of change set is a bit smaller now. So, I think the idea of two hooks on creation is better. It tries to put prep-creation hook according to the manner of existing DAC checks, and post-creation hook is next to modification of system catalogs with same visibility of the main entries. It seems to me this simple principle enables to minimize our task to understand and maintain. Thanks, (2010/10/08 9:39), KaiGai Kohei wrote: > (2010/10/08 0:21), Robert Haas wrote: >> On Wed, Oct 6, 2010 at 5:21 PM, Alvaro Herrera >> <alvherre@commandprompt.com> wrote: >>> Excerpts from Robert Haas's message of mié oct 06 17:02:22 -0400 2010: >>>> 2010/10/5 KaiGai Kohei<kaigai@ak.jp.nec.com>: >>> >>>>> However, we also have a few headache cases. >>>>> DefineType() creates a new type object and its array type, but it does not >>>>> call CommandCounterIncrement() by the end of this function, so the new type >>>>> entries are not visible from the plugin modules, even if we put a security >>>>> hook at tail of the DefineType(). >>>>> DefineFunction() also has same matter. It create a new procedure object, >>>>> but it also does not call CommandCounterIncrement() by the end of this >>>>> function, except for the case when ProcedureCreate() invokes language >>>>> validator function. >>>> >>>> So I guess the first question here is why it's important to be able to >>>> see the new entry. I am thinking that you want it so that, for >>>> example, you can fetch the namespace OID to perform an SE-Linux type >>>> transition. Is that right? >>> >>> I'm not sure that there's any point trying to optimize these to the >>> point of avoiding CommandCounterIncrement. Surely DefineType et al are >>> not performance-sensitive operations. >> >> OK, fair enough. Let's just do it unconditionally then. >> > I guess we will need to have such kind of discussion whenever we touch > the code around security hooks in the future, if hooks would not be put > next to the existing DAC checks. > Although we need to define several hooks on object creation in addition > to the main hook, separating it into two parts helps us to understand > and maintenance. > > | In the case when we have two hooks, obviously, the prep-creation > | hook will be after the DAC checks, and the post-creation hook will > | be after the insert/update of system catalogs. > > I still don't think such a simple principle overs our capability, and > also don't think it is more complex than matters around the idea of > only post-creation hooks, such as CommandCounterIncrement(). > > Thanks, -- KaiGai Kohei <kaigai@ak.jp.nec.com>
В списке pgsql-hackers по дате отправления: