Thread

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

Kohei KaiGai <kaigai@kaigai.gr.jp> — 2011-07-11T20:52:43Z

I rebased the userspace access vector cache patch to the latest tree.

I'll describe the background of this patch because this thread has not been
active more than a week.
The sepgsql asks in-kernel selinux when it needs to make its access control
decison, so it always causes system call invocations.
However, access control decision of selinux for a particular pair of security
label is consistent as long as its security policy is not reloaded.
Thus, it is a good idea to cache access control decisions recently used in
userspace.
In addition, current GetSecurityLabel() always open pg_seclabel catalog and
scan to fetch security label of database objects, although it is a situation we
can utilize syscache mechanism.

The "uavc-syscache" patch adds a new SECLABELOID syscache.
It also redefine pg_seclabel.provide as Name, instead of Text, according to
the suggestion from Tom.
(To avoid collation conscious datatype)

The "uavc-selinux-cache" patch adds cache mechanism of contrib/sepgsql.
Its internal api to communicate with selinux (sepgsql_check_perms) was
replaced by newer sepgsql_avc_check_perms that checks cached access
control decision at first, prior to system call invocations.

The result of performance improvement is obvious.

* Test 2. time to run 50,000 of SELECT from empty tables
 selinux | SECLABELOID syscache
  avc   |   without |   with
---------+-----------------------
 without | 185.59[s] | 178.38[s]
---------+-----------------------
 with    |  23.58[s] |  21.79[s]
---------+-----------------------

I strongly hope this patch (and security label support on shared objects) to
get unstreamed  in this commit-fest, because it will perform as a basis of
other upcoming features.
Please volunteer the reviewing!

Thanks,

2011/7/2 Kohei KaiGai <kaigai@kaigai.gr.jp>:
> The attached patch re-defines pg_seclabel.provider as NameData, instead of Text,
> and revert changes of catcache.c about collations; to keep consistency with the
> security label support on shared objects.
> All the format changes are hidden by (Get|Set)SecurityLabel(), so no
> need to change
> on the patch to contrib/sepgsql.
>
> Thanks,
>
> 2011/6/13 Kohei KaiGai <kaigai@kaigai.gr.jp>:
>> 2011/6/13 Robert Haas <robertmhaas@gmail.com>:
>>> On Mon, Jun 13, 2011 at 7:51 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
>>>> For syscache, length of a typical security label in selinux is
>>>> less than 64 bytes. If we assume an entry consume 128bytes
>>>> including Oid pairs or pointers, its consumption is 128KBytes
>>>> per 1,000 of tables or others.
>>>> (Do we have a way to confirm syscache status?)
>>>
>>> I was thinking you might start a new session, SELECT pg_backendd_pid()
>>> to get the PID, use top/ps to get its memory usage; then do a bunch of
>>> stuff and see how much it's grown.  The difference between how much it
>>> grows with and without the patch is the amount of additional memory
>>> the patch consumes.
>>>
>> I checked memory consumption of the backend with / without
>> patches. Because sepgsql_restorecon() tries to reset security
>> label of all the schemas, relations, columns and procedures,
>> an execution of this function is suitable to emphasize differences
>> between two cases in maximum.
>>
>> The results shows us about 3MB of additional consumption
>> in VmRSS, even if it caches all the security label of the objects
>> being created in the default (3331 entries).
>>
>> * without patches before/after sepgsql_restorecon()
>>
>> VmPeak:   150812 kB -> 170864 kB
>> VmSize:   150804 kB -> 154712 kB
>> VmLck:         0 kB -> 0kB
>> VmHWM:      3800 kB -> 22248 kB
>> VmRSS:      3800 kB -> 10620 kB
>> VmData:     1940 kB ->  5820 kB
>> VmStk:       196 kB -> 196 kB
>> VmExe:      5324 kB -> 5324 kB
>> VmLib:      2468 kB -> 2468 kB
>> VmPTE:       108 kB -> 120 kB
>> VmSwap:        0 kB -> 0kB
>>
>> * with patches before/after sepgsql_restorecon()
>> VmPeak:   150816 kB -> 175092 kB
>> VmSize:   150808 kB -> 158804 kB
>> VmLck:         0 kB -> 0 kB
>> VmHWM:      3868 kB -> 25956 kB
>> VmRSS:      3868 kB -> 13736 kB
>> VmData:     1944 kB -> 9912 kB
>> VmStk:       192 kB -> 192 kB
>> VmExe:      5324 kB -> 5324 kB
>> VmLib:      2472 kB -> 2472 kB
>> VmPTE:       100 kB -> 124 kB
>> VmSwap:        0 kB -> 0 kB
>>
>> Thanks,
>> --
>> KaiGai Kohei <kaigai@kaigai.gr.jp>
>>
>
>
>
> --
> KaiGai Kohei <kaigai@kaigai.gr.jp>
>



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