Re: [v9.1] sepgsql - userspace access vector cache - Mailing list pgsql-hackers

From Kohei KaiGai
Subject Re: [v9.1] sepgsql - userspace access vector cache
Date
Msg-id BANLkTimSmRFrrtKkxY=S253e3_H9dXVahQ@mail.gmail.com
Whole thread Raw
In response to Re: [v9.1] sepgsql - userspace access vector cache  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [v9.1] sepgsql - userspace access vector cache
List pgsql-hackers
2011/6/9 Robert Haas <robertmhaas@gmail.com>:
> On Thu, Jun 9, 2011 at 12:39 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
>> 2011/6/9 Robert Haas <robertmhaas@gmail.com>:
>>> On Thu, Jun 9, 2011 at 3:59 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
>>>> The only modification by this patch to the core routine is a new
>>>> syscache for pg_seclabel system catalog. The SECLABELOID enables to
>>>> reference security label of the object using syscache interface.
>>>
>>> I believe we decided against that previously on the grounds that we
>>> don't want to add syscaches that might get really really big.  In
>>> particular, there could be a LOT of labelled large objects floating
>>> around.
>>>
>> (Sorry, I missed to Cc: pgsql-hackers, so send again)
>>
>> As long as we use syscache mechanism to hold security label of
>> relation or other cached objects, do you think it cause no troubles?
>
> Maybe, but why do we need it?
>
Of course, I'd like to look up security label of the referenced object with
smallest cost as possible as we can.

Here is two level lookups.
The first is from object identifiers to security label; it can be boosted
using syscache mechanism. The second is from security labels to
access control decision; it can be boosted using userspace avc.

Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Postmaster holding unlinked files for pg_largeobject table
Next
From: Tom Lane
Date:
Subject: Re: Invalid byte sequence for encoding "UTF8", caused due to non wide-char-aware downcase_truncate_identifier() function on WINDOWS