Re: security label support, part.2

The attached patches are revised ones, as follows.

* A new SECURITY LABEL statement replaced the previous ALTER TABLE statement
  with SECURITY LABEL TO option. It has the following syntax.

  SECURITY LABEL [ FOR <provider> ] ON <object class> <object name> IS '<label>';

  E.g) SECURITY LABEL ON TABLE t1 IS 'system_u:object_r:sepgsql_table_t:s0';

* It supports multiple security providers to assign its security label on
  a database object. The pg_seclabel catalog was modified as follows:

    CATALOG(pg_seclabel,3037) BKI_WITHOUT_OIDS
    {
        Oid     reloid;     /* OID of table containing the object */
        Oid     objoid;     /* OID of the object itself */
        int4    subid;      /* column number, or 0 if not used */
+       text    tag;        /* identifier of external security provider */
        text    label;      /* security label of the object */
    } FormData_pg_seclabel;

  The new 'tag' field identifies which security provider manages this
  security label. For example, SE-PostgreSQL uses "selinux" for its
  identifier.

* The security hook to check relabeling become to be registered using
  register_object_relabel_hook() which takes a tag of ESP module and
  a function pointer to the security hook.
  ExecSecLabelStmt() picks up an appropriate security hook, then it
  shall be invoked even if multiple modules are loaded.

* Add _copySecLabelStmt() on nodes/copyfuncs.c and _equalSecLabelStmt()
  on nodes/equalfuncs.c, because I forgot to add them, although new
  parsenode (SecLabelStmt) was added.

* Add descriptions about pg_seclabel catalog and SECURITY LABEL statement
  on the documentation.

Thanks,

(2010/07/23 22:36), Robert Haas wrote:
> On Fri, Jul 23, 2010 at 8:59 AM, KaiGai Kohei<kaigai@kaigai.gr.jp>  wrote:
>> (2010/07/23 20:44), Robert Haas wrote:
>>>
>>> 2010/7/23 KaiGai Kohei<kaigai@ak.jp.nec.com>:
>>>>>
>>>>> Hmm.  How about if there's just one provider loaded, you can omit it,
>>>>> but if you fail to specify it and there's>1 loaded, we just throw an
>>>>> error saying you didn't specify whose label it is.
>>>>>
>>>> Perhaps, we need to return the caller a state whether one provider
>>>> checked
>>>> the given label at least, or not.
>>>
>>> Return to the caller?  This is an SQL command.  You either get an
>>> error, or you don't.
>>>
>> Ahh, I was talked about relationship between the core PG code and ESP
>> module.
>> It means the security hook returns a state which informs the core PG code
>> whether one provider checked the given label, then the core PG code can
>> decide whether it raise an actual error to users, or not.
>>
>> In other words, I'd like to suggest the security hook which returns a tag
>> of ESP module, as follows:
>>
>>   const char *
>>   check_object_relabel_hook(const ObjectAddress *object,
>>                             const char *provider,
>>                             const char *seclabel);
>
> I don't think that's a very good design.  What I had in mind was a
> simple API for security providers to register themselves (including
> their names), and then the core code will only call the relevant
> security provider.  I did try to explain this in point #3 of my
> original review.
>


--
KaiGai Kohei <kaigai@ak.jp.nec.com>