[Rpm-maint] [PATCH 10/19] Add new policy requires tag to spec file format

[Steve Lawrence]

On Fri, 2010-02-05 at 12:33 -0500, James Antill wrote:
> On Tue, 2010-02-02 at 15:25 -0500, Steve Lawrence wrote:
> > The PolicyRequires tag is used to specify which versions of packages are
> > required by policies installed in the module. The PolicyRequires tag has
> > the same syntax as the Requires tag.
> > 
> > Assume libselinux-1.2 is installed on the system. Package foo-1.0 has a
> > policy module that 'Requires: libselinux >= 1.3'. Running the command:
> > 
> > rpm -Uvh foo-1.0.rpm libselinux-1.3.rpm
> > 
> > would meet all normal dependencies. However, the policy installation
> > would still fail because a policy module in foo requires a newer version
> > of libselinux than is on the system at the time of policy installation
> > (at the beginning of the transaction). The solution would be to install
> > the packages in two separate transactions:
> > 
> > rpm -Uvh libselinux-1.3.rpm
> > rpm -Uvh foo-1.0.rpm
> > 
> > However, this is unintuitive and not always possible.
> > 
> > The new PolicyRequires directive solves this problem.
> 
>  Again, IMNSO, this just argues for making real "policy only" packages,
> and then prco data will just work.
> 

You've mentioned the issue of using separate policy packages throughout
your replies, so we'll respond to all of those here.

Using separate packages will create a large number of packages, and we
started this project with the requirement that this was unreasonable
[1]. That said, even without this limitation (which we now understand to
be acceptable [2]) we still believe the new %policy section has more
advantages than separate packages. Additionally, separate packages
aren't a magic bullet and things won't "just work."

In terms of third parties and end users, the %policy section is better
than separate packages. Distributing policy is as simple as adding the
%policy section to an existing package. Third parties don't need to
worry about distributing policy packages along with their main package,
and multiple policy types can be included along with the application in
a single package. With policy in separate packages, you would need a
separate package for each policy type (e.g. mls, targeted), resulting in
multiple policy packages that third parties need to deal with
distributing.

In terms of end users, the %policy section greatly reduces the chance of
error. Forgetting to install a policy for an application or installing
the wrong policy could easily lead to an unusable system. Requires can
help to minimize this, but for users who don't understand SELinux this
is certainly a possibility. Having everything in a single package and
hidden from the user is a big plus in terms of making SELinux in RPM
usable.

Also, this method is flexible enough that if you want to have policies
in separate packages, you can do so. This doesn't require that policy be
included with an application.

In terms of actual implementation, using separate packages still has
issues and things won't "just work."

Rpm doesn't guarantee ordering. It tries its best, but there are no
strict ordering constraints to ensure that policy is installed at the
correct time. Ordering is very important with respect to when policy is
installed, which rpm can't currently provide.

Requirements are also an issue. For example, a package could require
that a specific policy module is required, but how do you deal with
multiple types? You might have separate policy packages like:

policy-foo-targeted.rpm
policy-foo-mls.rpm

How does the right policy package get installed when you install
foo.rpm? It can require 'policy-foo' which is Provided by both poilcy
packages, but how is the correct one installed. You can't randomly pick
one that provides 'policy-foo' and you shouldn't need to require end
users to install the right one for the policy type their using. You
could pick the right one based on the current systems policy type, but
it's possible that could change during a transaction, so now the
requirements must change in the middle of a transaction? How do you
handle that?

A related issue is users who don't want SELiux policy installed. If
'policy-foo' is required, something must satisfy that. Using
--norequires is a terrible option, so you end up adding a dummy package
that provides 'policy-foo' but doesn't actually do anything, which is
almost as bad.

Obsoletes and conflicts have similar issues, which is why we have our
own for policy modules.

All this is not to say that separate policy packages isn't doable. These
problems could certainly be solved, but it won't "just work." Plus, the
%policy section is quite a bit more flexible and friendly to third
parties and end users.

- Steve

[1] http://marc.info/?l=selinux&m=114658781128088&w=2
[2] http://lists.rpm.org/pipermail/rpm-maint/2009-October/002585.html