Horton

Re: [v9.1] sepgsql - userspace access vector cache

Kohei KaiGai <kaigai@kaigai.gr.jp>

View thread
From: Kohei KaiGai <kaigai@kaigai.gr.jp>
To: Stephen Frost <sfrost@snowman.net>
Cc: PgHacker <pgsql-hackers@postgresql.org>
Date: 2011-06-09T16:54:37Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Remove the limit on the number of entries allowed in catcaches, and

2011/6/9 Stephen Frost <sfrost@snowman.net>:
> * 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.
>
> Perhaps I'm missing it, but.. why is this necessary to implement such a
> cache?  Also, I thought the SELinux userspace libraries provided a cache
> solution?  This issue is hardly unique to SELinux in PostgreSQL...
>
I'm concerned about its interface, although it might be suitable for
X-Windows...

Its avc interface identifies security context using a pointer of
malloc()'ed cstring.
In our case, we need to look up this security context on the hash managed by
libselinux using the result of syscache lookup. It is quite nonsense.

In addition, avc of libselinux confirms whether the security policy is reloaded
for each avc lookup, unless we launch a system state monitoring thread.
But, it is not a suitable design to launch a worker thread for each
pgsql backend.

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