[Rpm-maint] [PATCH v2 3/5] Add common Collection requirements

[Panu Matilainen]

On Thu, 24 Jun 2010, Steve Lawrence wrote:

> On Thu, 2010-06-24 at 09:29 +0300, Panu Matilainen wrote:
>> On Wed, 23 Jun 2010, Steve Lawrence wrote:
>>> On Wed, 2010-06-23 at 11:13 +0300, Panu Matilainen wrote:
>>>>
>>>> Hmm, this sounds somewhat familiar... isn't this basically a case of "if
>>>> these packages are present in transaction, order them before me but do not
>>>> actually require them"? The kernel/initrd folks have been requesting such
>>>> a feature for a long time. If we can do this in a way that serves both,
>>>> all the better.
>>>>
>>>> Not sure if you've decided something concrete on the outcome of the
>>>> previous selinux policy packaging discussion (thread starting at
>>>> http://lists.rpm.org/pipermail/rpm-maint/2010-April/002698.html) but for
>>>> at least some of the variants something like this seems workable:
>>>
>>> Yes, we've decided we would split all policy into a separate *-policy
>>> packages with the main package requiring it. So apache-policy contains
>>> all policies (mls, targeted, etc) and apache requires apache-policy.
>>
>> Oh, the main package *requires* the policy? In that case you dont need any
>> extra ordering to get policies installed before the apps they protect, rpm
>> guarantees requires to be installed before the requiring package (except
>> if there are dependency loops, but there shouldn't be those in this case).
>>
>> The order-hint thingie was under the assumption the policies are not
>> required (to avoid unnecessarily dragging them in on systems where selinux
>> isn't enabled). Or was the hard requirement decided just because there is
>> no other way to establish the relation in rpm currently?
>>
>
> One reason we used the hard requires is because it's already available
> in RPM. Though it's nice because users don't have to think about it. If
> someone yum installs apache, apache-policy will automatically be
> installed. If they are on an selinux enabled machine, they don't have to
> manually install the apache-policy package when they install apache.
>
> Similarly, you wouldn't be able to remove apache-policy without removing
> apache, which is nice security-wise, since removing policy can be
> dangerous.
>
> As for unnecessarily dragging in policy packages on a machine where
> SELinux isn't enabled, while the packages will be installed, the selinux
> plugin will only actually install policies if SELinux is enabled. So you
> would just end up with policy packages installed, but not the actually
> policies. I believe we've mentioned this before in a previous email, and
> the consensus was that it wasn't a big deal.

Ok, I've probably missed that tidbit in the discussions, thanks for 
clarifying. I agree making them good old hard requires keeps things a 
whole lot simpler. I do suspect /somebody/ will complain about "all that 
unnecessary bloat getting dragged in" but policy packages can be expected 
to be very small and without further dependencies in general I think.

>>>> Taking again apache and its policy/policies as an example...
>>>> If either all the policies are included in a single package, or provide a
>>>> common thing regardless of the variant, then the main apache package could
>>>> have something like this (ignore the exact spec syntax for now):
>>>>
>>>> Requires(order): apache-policy
>>>>
>>>> ...which creates a kind of soft dependency between apache-policy and
>>>> apachge, which dependency resolution ignores but ordering takes into
>>>> account as if it were a real dependency, ie anything providing
>>>> "apache-policy" needs installing before "apache" itself.
>>>>
>>>> IF this kind of approach works for selinux policies then it's not even
>>>> collection specific, it'd be just a common mechanism which collections
>>>> use, and kernel/initrd folks would be happy too.
>>>
>>> It seems like this could work. So if I understand it correctly, a more
>>> complicated selinux example with two packages, each with a policy, might
>>> look like this?
>>>
>>> foo-policy:
>>>  Requires: collection(selinux-policies)
>>>  Provides: sepolicy
>>>
>>> bar-policy:
>>>  Requires: collection(selinux-policies)
>>>  Provides: sepolicy
>>
>> Hmm.. are these two providing the same thing on purpose? I don't quite see
>> what that would accomplish, except chaos and confusion :)
>>
>
> SELinux has some special ordering requirements that can't be met by the
> standard provdies/requires, which is the purpose of the "Add common
> collection requires" patch, which as I've found out, will probably break
> things. For example, say we these foo/bar rpms without the
> Requires(order)/Provides sepolicy. Then rpm could order the installation
> like so:
>
> 1. selinux-policy
> 2. foo-policy
> 3. foo
> 4. bar-policy
> 5. bar
>
> With this ordering, the SELinux collection plugin will get triggered
> after bar-policy is installed (it's the last member of the
> selinux-policies collection). This means foo will already be installed
> when policy is loaded and any SELinux labels installed by foo-policy
> won't get applied to foo.
>
> The idea with the Requires(order): sepolicy is that anything that
> Provides: sepolicy would be ordered before anything that
> Requires(order): sepolicy. So because foo Requires(order): sepolicy, and
> bar-policy provides sepolicy, bar-policy would be installed first. So
> the order becomes:
>
> 1. selinux-policy
> 2. foo-policy
> 3. bar-policy
> 4. foo
> 5. bar
>
> And everything works with policy, but doesn't change the ordering for
> anything else, at least that's the idea.

Right, I see the point now (I had doubts about the interleaved installs 
but spelling it out makes it bleeping obvious :) But I dont think 
that'll work, as *any* of the packages providing "sepolicy" will satisfy 
the dependency, ie once either foo-policy or bar-policy is installed, 
"sepolicy" is provided and the other things can proceed.

So ok, this does need some special flag. And I've a feeling some other 
collection-uses might need it too. Many of the "update this cache 
somewhere within the transaction" cases don't care, but if collections are 
used for something that directly affects basic runnability of the 
applications/tools then there needs to be a way to tell rpm that the 
entire collection must have been installed and executed before the 
anything depending on the collection members can be installed. Which is 
AFAICS the same as the selinux-case, even if for somewhat different 
reasons.

 	- Panu -