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

[James Antill]

On Fri, 2010-02-12 at 15:34 -0500, Steve Lawrence wrote:

> 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].

 I understand Jeremy's concern, but to be fair I don't think he was
weighing more packages against rpm creating new magic packages on
package removal of other things :).

>  Additionally, separate packages
> aren't a magic bullet and things won't "just work."

 Sure, I understand there will still be some problems that need solving
that isn't what I meant by "just work". What I meant is that I _know_
things in yum are going to be unhappy if a transaction to "remove X"
actually starts doing things like "remove X; install fake-X-blah;
install fake-X-snafu". 
 Then there's the fact of what happens when a user runs "yum remove
fake-X-blah", or installs something which obsoletes/conflicts with it
etc. IMO putting gpg keys into the rpmdb was a big mistake, and we've
had to work around it at higher levels ... your pseudo packages would be
even worse as they would have full (and separate) prco data with them as
well as just data.

 I can see a huge number of problems happening due to having two sets of
not integrated dependencies.
 And I'd bet a lot of money that you'll need real prco resolution, even
if you don't have it yet. And I'd bet a smaller amount that you need
integrated transaction ordering (ie. some policy installed, then some
installs/scriplets, then more policy etc.).

> 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.

 The specfile stuff can all stay the same, rpmbuild would just spit out
extra packages instead of doing headers. And sure more than one package
is hard to deal with using just rpm, but nobody should be using just
rpm.

> 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.

 Please define what you mean here, as far as I know the only ordering
problem rpm has "ever" had is ordering on removal of packages -- and
that is now fixed.
 I worry a lot that you'll eventually need all the features of rpm
transaction ordering ... and will then still have problems because
they'll be two transaction orders (policy and install/scriplets) which
won't speak to each other.

> 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?

 This is a problem, one solution that comes to mind is for all policy
types (mls, targeted, empty, whatever) to be in a single package and
then the SELinux bit is localized to knowing which types to operate on.
This does mean that you can't require/obsolete differently for different
types though, so maybe that isn't a usable solution.
 Maybe we have to do something "clever" so that the you can do 
"Require: policy-foo" and it brings in all the packages that provide
policy-foo. Maybe we have to do something in yum's compare_providers so
that yum gets the correct provider of policy-foo for the system.

> 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.

 It's _much_ less bad, IMO. As the installed prco data is solvable which
is a huge thing.
 Saying that personally I think we can ignore this, the user can install
the policy but it not do anything by just turning SELinux off. And your
--nopolicy solution has the same problem, limited to pseudo packages,
and so is going to be just as bad IMO.

-- 
James Antill - james at fedoraproject.org
http://yum.baseurl.org/wiki/releases
http://yum.baseurl.org/wiki/whatsnew/3.2.26
http://yum.baseurl.org/wiki/YumMultipleMachineCaching