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(at)kaigai(dot)gr(dot)jp> wrote:
>> (2010/07/23 20:44), Robert Haas wrote:
>>>
>>> 2010/7/23 KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)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(at)ak(dot)jp(dot)nec(dot)com>