From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> |
Cc: | Kohei Kaigai <Kohei(dot)Kaigai(at)emea(dot)nec(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [v9.2] SECURITY LABEL on shared database object |
Date: | 2011-07-05 14:19:18 |
Message-ID: | CA+Tgmob4vy+xR4+ZuYd3cdaa5J5UAR6w6nBV4j=Uh26j7BZ+Ng@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jun 13, 2011 at 2:33 PM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
> 2011/6/13 Robert Haas <robertmhaas(at)gmail(dot)com>:
>> On Mon, Jun 13, 2011 at 1:40 PM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
>>> 2011/6/13 Robert Haas <robertmhaas(at)gmail(dot)com>:
>>>> On Mon, Jun 13, 2011 at 12:24 PM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)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.
Hmm, OK. I guess what I'm not sure about is - how much should we
worry about the fact that this creates several more shared (and
therefore nailed?) system catalogs? Anyone have an opinion on that?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-07-05 14:21:29 | Re: testing nested case-when scoping |
Previous Message | Robert Haas | 2011-07-05 14:10:36 | Re: Small SSI issues |