Re: [v9.1] sepgsql - userspace access vector cache - Mailing list pgsql-hackers
From | Kohei KaiGai |
---|---|
Subject | Re: [v9.1] sepgsql - userspace access vector cache |
Date | |
Msg-id | CADyhKSW04tAhWgtqD=WgbQ9-nGD7EEAUe6HKV2__Zo=cXcLb0g@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 |
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>
Attachment
pgsql-hackers by date: