Re: security hooks on object creation

2010/11/9 KaiGai Kohei <kaigai@ak.jp.nec.com>:
> The attached patch provides plugin modules a hook just after object
> creation time. In typical use cases, it enables to assign default
> security labels on object creation by the external security providers.
>
> As Robert suggested before, it provides a generic purpose main hook.
> It takes an enum of ObjectAccessType which informs plugins what kind
> of accesses are required, and identifier of the object to be referenced.
> But, in this version, no additional information, such as new name in
> ALTER xxx RENAME TO, are not supported.
>
> The ObjectAccessType is defined as follows:
>
>  typedef enum ObjectAccessType {
>    OAT_POST_CREATE,    /* Post creation fixups; such as security labeling */
>  } ObjectAccessType;
>
> We will support more complete kind of access types in the future version,
> however, we focus on default labeling rather than DDL permissions right
> now, so only OAT_POST_CREATE is defined here.
> Perhaps, we will add OAT_ALTER, OAT_DROP, OAT_COMMENT and so on.
>
> In this patch, I put hooks on the place just after creation of database
> objects that we can assign security labels. (schema, relation, attribute,
> procedure, language, type, large object)
>
> However, I didn't touch or move CommandCounterIncrement() yet, although
> we had a long discussion MVCC visibility of new object.
> Because I'm not clear whether it is really preferable to inject CCIs
> onto random points such as TypeCreate() or ProcedureCreate() under
> development of the version killed by myself.
> (In other words, it was simply ugly...)
>
> At least, we can see the new entries with SnapshotSelf, although we will
> pay performance penalty. If so, it is an idea not to touch anything
> related to CCIs.
> The purpose of post creation hooks are assignment of default security
> labels, not DDL permissions. So, it is not a bad idea not to touch
> routines related to CCIs in the earlier version of external security
> provider.
>
> In this patch, we put InvokeObjectAccessHook0 on the following functions.
>
> - heap_create_with_catalog() for relations/attributes
> - ATExecAddColumn() for attributes
> - NamespaceCreate() for schemas
> - ProcedureCreate() for aggregates/functions
> - TypeCreate() and TypeShellMake() for types
> - create_proc_lang() for procedural languages
> - inv_create() for large objects

I think you ought to try to arrange to avoid the overhead of a
function call in the common case where nobody's using the hook.
That's why I originally suggested making InvokeObjectAccessHook() a
macro around the actual function call.

I don't want to refer to this as a framework for enhanced security
providers.  Let's stick with the term "object access hook".  Calling
it an enhanced security provider overspecifies; it could equally well
be used for, say, logging.

Is there any compelling reason not to apply this to every object type
in the system (e.g. all the ones COMMENT can apply to)?  I don't see
any reason to restrict it to the set of objects to which it's sensible
to apply security labels.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company