Re: security label support, part.2 - Mailing list pgsql-hackers
From | KaiGai Kohei |
---|---|
Subject | Re: security label support, part.2 |
Date | |
Msg-id | 4C4D32F9.9050805@ak.jp.nec.com Whole thread Raw |
In response to | Re: security label support, part.2 (Robert Haas <robertmhaas@gmail.com>) |
Responses |
Re: security label support, part.2
|
List | pgsql-hackers |
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>
Attachment
pgsql-hackers by date: