Re: [v9.2] Object access hooks with arguments support (v1)

2011/11/8 Robert Haas <robertmhaas@gmail.com>:
> On Mon, Nov 7, 2011 at 12:20 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
>> If sepgsql would apply permission checks db_procedure:{install} on the
>> OAT_POST_CREATE hook based on the funcion-oid within new entry of
>> system catalog, we can relocate OAT_PREP_CREATE hook more conceptually
>> right place, such as just after the pg_namespace_aclcheck() of DefineType().
>> On the other hand, we may need to answer why these information are NOT
>> delivered on the OAT_PREP_CREATE hook without knowledge of sepgsql
>> internal.
>
> I'm having a hard time understanding this.
>
> Can you strip this patch down so it just applies to a single object
> type (tables, maybe, or functions, or whatever you like) and then
> submit the corresponding sepgsql changes with it?  Just as a demo
> patch, so I can understand where you're trying to go with this.
>
I tried to strip the previous patch into small portion per object types.
Part-1 for database, Part-2 for schema, Part-3 for relations, and
Part-4 for functions.

The basic idea is the prep-creation hook informs the sepgsql module
properties of the new object being constructed. According to the
previous discussion, all the arguments are commonly used to existing
DAC checks also. Then, this hook allows to write back its private
opaque to be delivered to the post-creation hook; likely used to deliver
security label of the new object to be assigned.

However, I become unsure whether it is a good idea to put prep-creation
hook on all the object, because it takes many boring interface changes
to deliver private datum, and we're probably able to implement similar
stuff with post-creation hook except for a few object types.

I guess the following (A) and (B) are the only case that needs prep-
creation hooks for permission checks. Elsewhere, sepgsql will be
able to make its decision based on the entry of system catalogs
on post-creation hook.

(A) In the case when we want to apply checks based on information
that is not contained within system catalogs.
E.g, Oid of source database on CREATE DATABASE. Existing DAC
checks ownership of the database, if not template.

(B) In the case when we want to distinguish code path between user's
query and system internal stuff.
E.g, heap_create_with_catalog() is also called by make_new_heap()
as a part of ALTER TABLE, but it is quite internal stuff, so not suitable
to apply permission checks here.

It seems to me, using post-creation hooks makes the patch mode simple
to implement permission checks; except for above two object types.
So, I'd like to adopt approach to put prep-creation hooks on limited number
of object types, not symmetric with post-creation hook.
How about your opinion about this?

Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>