Re: [meta-selinux][PATCH] bzip SELinux policy modules in ${datadir}

[Philip Tricca <flihp@twobit.us>]

On 12/03/2013 04:35 PM, Joe MacDonald wrote:
> (resending, this time including the list ...)
> 
> [Re: [meta-selinux][PATCH] bzip SELinux policy modules in ${datadir}] On
> 13.10.21 (Mon 16:15) Joe MacDonald wrote:
> 
>> [[meta-selinux][PATCH] bzip SELinux policy modules in ${datadir}] On 13.10.21
>> (Mon 18:06) Philip Tricca wrote:
>>
>>> The 'semodule' utility can operate on compresed modules so the only
>>> cost of this change is a slower module load time when invoking
>>> 'semodule -i' on a running system (increased CPU load due to bzip2).
>>> That said my tests show more than 100M reduction in ext3 image size
>>> of core-image-selinux. This last metric is a bit skewed as the image
>>> includes two policies. Still, a reduction in the size of the refpolicy
>>> package by 1/2 is significant.
>>
>> This is included in the batch of updates I've merged and are currently
>> staging in my tree.  FWIW, on my build I saw a similar reduction in size
>> to what you've reported, ~110MB, with a minor hit at load time.  As
>> expected there's also an increase in memory requirements at load time,
>> so I'm poking around a bit to see what this does to the lower-end
>> configurations I've got kicking around.  It'd be really nice if this was
>> an option rather than an on/off thing.
> 
> This took rather longer than I'd hoped.  :-/
> 
> Anyway, I tried a bunch of different configurations and didn't find a huge hit
> on memory requirements by doing this, though I still think there's an advantage
> to making this an option that can be turned off for folks where storage is cheap
> and memory and processing power is at a premium.  That, and the discussion on
> the SELinux mailing list along the same line where the general feeling was that
> smaller policies are better achieved by actually having less policy rather than
> compressing it, led me to this idea.
> 
> A DISTRO_FEATURE that is on by default and incorporates your patch.  What do you
> think, Phil?

Sounds good Joe. Thanks for getting this one in.

- Philip