Re: [v9.1] sepgsql - userspace access vector cache
От | Robert Haas |
---|---|
Тема | Re: [v9.1] sepgsql - userspace access vector cache |
Дата | |
Msg-id | BANLkTikxXVS9q0LKEN+=beTG=Y9A+cHY7Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [v9.1] sepgsql - userspace access vector cache (Kohei KaiGai <kaigai@kaigai.gr.jp>) |
Ответы |
Re: [v9.1] sepgsql - userspace access vector cache
|
Список | 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 по дате отправления: