Marking selinux policy binary as a config file - can we do it?

James Antill james at fedoraproject.org
Wed Jun 1 15:17:00 UTC 2011


On Wed, 2011-06-01 at 10:54 -0400, Eric Paris wrote:
> The selinux-policy rpm works by installing a bunch of binary policy
> modules and then in post it will call some selinux tools which take all
> of the modules along with local user configuration and local user
> modules and will build a final binary policy file.  This takes a lot of
> time and a lot of memory.  (In one test we see that this building of the
> final binary doubles the memory needed by anaconda during install).
> Obviously work needs to be done on these tools to fix both the time and
> the memory usage, and there is some traction along those lines but
> nothing substantial in the near term.
> 
> Since the vast majority of users don't make any local modules or any
> local configuration, I suggest that we include a final version of the
> binary policy file inside the RPM built at rpmbuild time marked as a
> config file.  Thus if a user makes no local changes to selinux policy
> the rpm install/update will just drop a new final policy binary into
> place and will never locally run the policy compilation tools.
> 
> My suggestion (and here is where I need people who understand rpm) was
> that in post we could test for the existence of a .rpmsave final binary
> policy file.  If we found it we would know that the user had some local
> configuration and that their final binary policy was not the same as the
> one included inside the rpm.  Thus we could delete the .rpmsave and run
> the tools to rebuild a final binary policy on the end station.

 No, don't test for .rpmsave files ... in theory you could do it with
md5sums, possible by doing something like:

build-selinux-policy -o foo
md5sum foo > .foo.md5sum

...at rpmbuild time and then compare that on upgrade (test would need to
be done in %pre, but acted upon in %post -- which is horrible).

 Another option might be to just mark it as "config-noreplace", and then
test if you've got the newer version in %post (via. the md5sum
method) ... if you haven't got the newer version you'd need to rebuild.

 Also I don't see how this can work with "externally packaged policy"
like pure-ftpd-selinux etc. ... which I thought was "the future".



More information about the Rpm-list mailing list