2011/6/13 Robert Haas <robertmh...@gmail.com>: > On Mon, Jun 13, 2011 at 1:40 PM, Kohei KaiGai <kai...@kaigai.gr.jp> wrote: >> 2011/6/13 Robert Haas <robertmh...@gmail.com>: >>> On Mon, Jun 13, 2011 at 12:24 PM, Kohei KaiGai <kai...@kaigai.gr.jp> wrote: >>>> The attached patch is an update revision of security label support >>>> for shared database objects. >>> >>> I'm kind of unexcited about this whole idea. Adding a shared catalog >>> for a feature that's only of interest to a small percentage of our >>> user population seems unfortunate. >>> >>> Are there any other possible approaches to this problem? >>> >> If unexcited about the new shared catalog, one possible idea >> is to add a new field to pg_database, pg_tablespace and >> pg_authid to store security labels? >> >> The reason why we had pg_seclabel is to avoid massive amount >> of modifications to system catalog. But only 3 catalogs to be >> modified to support security label on shared object. > > I guess maybe my real question here is - what do you plan to do with > those security labels, from a security perspective? For example: > roles. The user's security contect AIUI is passed over from the > remote side; his DAC role doesn't even enter into it from a MAC > perspective. Or does it? > The current primary target of security label of shared object is to acquire control on databases. It performs as a basis to compute default security label of underlying objects, and I also plan to control when we open the connection like ACL_CONNECT. Right now, we assume any database has "system_u:object_r:sepgsql_db_t:s0", then the default security label of schema objects are computed. (See sepgsql_schema_post_create in contrib/sepgsql/schema.c)
Regarding to the pg_tablespace and pg_authid, I have a plan to control DDL statements on these objects, However, its priority is not higher than databases or other non-shared objects such as tables or procedures. Thanks, -- KaiGai Kohei <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
