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

From Robert Haas
Subject Re: [v9.1] sepgsql - userspace access vector cache
Date
Msg-id BANLkTikxXVS9q0LKEN+=beTG=Y9A+cHY7Q@mail.gmail.com
Whole thread Raw
In response to Re: [v9.1] sepgsql - userspace access vector cache  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Responses Re: [v9.1] sepgsql - userspace access vector cache
List pgsql-hackers
On Thu, Jun 9, 2011 at 12:54 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
> 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.

So you're going to depend on the syscache not to move the pointers
around?  Yikes.

> 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.

I thought there was something you could mmap() into each backend...?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [v9.1] sepgsql - userspace access vector cache
Next
From: Bruce Momjian
Date:
Subject: Re: procpid?