[Rpm-maint] [PATCH 11/19] Parse new policy requires header and check policy dependencies

[Steve Lawrence]

On Thu, 2010-03-04 at 12:56 +0200, Panu Matilainen wrote:
> On Tue, 2 Feb 2010, Steve Lawrence wrote:
> 
> > After a policy set has been prepared (rpmpolsPrepare), a call to
> > rpmpolsCheckDeps will determine if PolicyReuqires: dependencies are met.
> > This function only checks against packages currently installed.
> >
> > Also, PolicyRequires are merged into Requires, so if normal dependency
> > checks pass, we know the PolicyRequries packages will be installed by the
> > end of the transaction.
> 
> The policy/module dependencies seem strangely familiar to me... obsoletes, 
> conflicts and requires. It should be possible to map them to the existing 
> dependency information, adding a parallel set of selinux (or anything else 
> for that matter) specific dependencies looks like road to madness to me.
> 
> Here's an idea, related to the pseudo-package issue too:
> 
> Instead of creating a parallel universe of dependencies and 
> pseudo-packages, turn the policy/module bits into transaction elements and 
> have them processed business as usual. Something in the lines of: detect 
> the presence of selinux modules in a package in rpmtsAddInstallElement() 
> create a header of the policy bits and add another transaction 
> element for it. That way the dependencies etc will get processed along 
> with everything else, instead of requiring a whole new set of things.
> 
> Or so the theory goes - sure it's going to need various enhancements here 
> and there, such as probably a new element type-bit so added policies would 
> be something like (TR_ADDED|TR_POLICY) and filter in various places etc.
> 
> And actually the case of pseudo-package generation here is a sub-case of 
> more generic "package(s) within a package" idiom which comes up every now 
> and then. If the policy parts were stored (at package build-time) in a 
> header of their own, nested inside the main package header (a header is 
> just binary data and headers can contain such data), 
> rpmtsAddInstallElement() could basically just grab the policy header and 
> call itself to add another element from it, no need for runtime 
> transformations of dependency and other data.

Another interesting idea that we'll have to give a bit more thought. But
it seems like a nice compromise between using rpm's PRCO with separate
policy packages, but still have them hidden from the users.

> Again, so the theory goes. I've no doubt various internals will need 
> tweaking to make it possible in practise.
> 
> BTW one very real issue with storing policies in headers (nested or not) 
> is that the header size is currently capped at 16MB, and people are 
> already hitting that limit occasionally. It takes a huge number of files 
> to reach that, but adding arbitrary amount of selinux modules into the 
> header is not going to do anything to help. The limit needs raising sooner 
> than later anyway, but packages with headers bigger than 16MB will be 
> unreadable by every rpm currently deployed, and there's no way to add a 
> nice little feature-tracking dependency for it.
> 
>  	- Panu -