[systemd-devel] SELinux support takes up ~15MB of memory?

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/07/2011 11:00 AM, Lennart Poettering wrote:
> On Fri, 07.01.11 10:18, Daniel J Walsh (dwalsh at redhat.com) wrote:
> 
>> On 01/07/2011 09:44 AM, Lennart Poettering wrote:
>>> On Fri, 07.01.11 09:40, Daniel J Walsh (dwalsh at redhat.com) wrote:
>>>
>>>>> Hmm, can we start with an empty loaded policy and then load additional
>>>>> parts of it as we go? i.e. if we encounter a socket /foo/bar/waldo we
>>>>> ask libselinux to load /foo/bar, and so on? Most likely 90% of the
>>>>> sockets will be in the same dir anyway (/var/run), so after the first
>>>>> socket everything we need should be loaded most of the time. However,
>>>>> since sockets can be configured dynamically to any place we might need
>>>>> to load policy for other areas, too. Hence if we could load hte policy
>>>>> bit by bit we should get relatively nice behaviour and only load a
>>>>> minimal subset of the policy into memory.
>>>>>
>>>>> Lennart
>>>>>
>>>> I think the library functions are there to do this, but you would have
>>>> to do the management of the paths.  libselinux I believe does not have
>>>> the capability to add a path after the initial load but you could have a
>>>> link list of paths connected to blobs of regexes.
>>>
>>> So, instead of loading one single policy blob we would basically load a
>>> number of independent policy blobs, but always only parts of the real
>>> thing? I guess that is quite doable, though I do wonder how the prefix
>>> finding algorithm should best look like...
>>>
>>> Lennart
>>>
>> Yes and you have a speed versus size thing.   Do you want to compile
>> /var once or /var/lock and /var/run or much worse /var/run/app1 and
>> /var/run/app2 ...
>>
>> I would not go above two directories.
>>
>> If you really want size versus speed you could free the blobs once you
>> got to a steady state, if you can figure out you are in a steady state.
>>  And then reload them if you need too.
> 
> Hmm, so, I wonder how far we could get by just hardcoding that we preload
> /var/run, /var/lock and /dev (the latter for /dev/initctl). That should
> cover 100% of the sockets/fifos of a usual install. And if that doesn't
> suffice we load the real deal on-demand.
> 
> So, loading parts of the policy apparently takes up less memory. How
> exactly is the speed of loading the policy influenced by this? I.e. is
> loading a part of the policy as CPU/IO intensive as loading the full thing?
> Or even more CPU intensive due to a lot of compares? Or cheaper?
> 
> Lennart
> 
I think it is just setup time.   If all you are labeling in /dev is
initctl, I would say just load that,  /dev has lots of labels, that udev
has to handle.  The library is call regcomp on each line.

grep ^/dev /etc/selinux/targeted/contexts/files/file_contexts | wc -l
277

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk0nQZEACgkQrlYvE4MpobMxSwCfTczLRvKuVly/APVLEhW3cp4P
WRcAoLuzneawNoV1/JlWhSmMuvCsxLkq
=cJj7
-----END PGP SIGNATURE-----