2011/6/9 Robert Haas <robertmhaas@gmail.com>:
> 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.
>
No. It is nonsense, because cached security label of table X and table Y
are allocated on different address, so it eventually invokes system calls
for each tables, even if these tables have identical security labels.
>> 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...?
>
The selinux_status_open() maps a status page of selinux that allows applications
to reference a flag to show whether the policy was reloaded, or not, without
system call invocations. This function is called when sepgsql
initializes itself,
then it shall be inherited to child processes.
(Please note that avc of libselinux does not use this feature yet...)
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
