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

Chad Sellers csellers at tresys.com
Tue Feb 16 20:51:49 UTC 2010


On 2/13/10 1:20 AM, "James Antill" <james at fedoraproject.org> wrote:

> 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 :).
> 
To be clear, these pseudopackages (similar to the gpg pseudopackages rpm
creates) are not created on package removal. They're created on package
install, and live on past package removal.

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

Again, that's not what this patch does. It creates the pseudopackage on
install, not removal.

>  Then there's the fact of what happens when a user runs "yum remove
> fake-X-blah"

Good point. This isn't handled well in the current patch. I'd say this
should cause the removal of policy. This way, the default behavior will be
to have policy remain but we give the users a way to decide to remove the
policy in a way that is consistent between the system and rpm's database.

>, 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.
> 
We did indeed follow the lead of gpg keys. If the implementation of gpg key
pseudopackages was a mistake, then so is this. We've tried our best to
conform to the rpm way of doing things, but perhaps that was a mistake here.

>  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.).
> 
I'm not much into gambling. I know of no scenarios that require that level
of complexity. Of course, I'm sure we missed some use cases, so please point
out any that you know of.

>> 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.
> 
Really? You may want everyone distributing software to set up a yum repo,
but that's not the state of the world we live in. Even if it were, many
software installs happen on machines disconnected from the Internet.
Creating additional packages does affect users.

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

Perhaps my understanding is wrong here. I thought rpm does not guarantee
order. It tries to order things in dependency order, and it guarantees that
all dependencies will be installed by the end of the transaction, but it
does not guarantee order. I thought this was necessary to handle things like
circular dependencies. My understanding was that rpm would arbitrarily break
these circles. Was I misunderstanding this?

>  I worry a lot that you'll eventually need all the features of rpm
> transaction ordering

Note that the policy install itself is orderless - it's a single
transaction. We've worked hard in SELinux to ensure that policy operations
could be done in a transactional way, and a goal of this is to be able to
utilize that.

>... and will then still have problems because
> they'll be two transaction orders (policy and install/scriplets) which
> won't speak to each other.
> 
Again, I don't understand your concern here. Policy is installed in one
operation at the beginning of the rpm transaction.

>> 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.
> 
All of this comes from the fact that rpm was not designed for this. If we go
down this route, we're going to end up creating special rpm packages that
have to be treated differently all over the place. My guess (only a guess at
this point) is that we'll end up with more special casing than we have now.

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

The point of this is not just for users who don't want to run SELinux. It's
for the users that want to write their own policy and the users that want to
choose a different policy as well.

> And your
> --nopolicy solution has the same problem, limited to pseudo packages,
> and so is going to be just as bad IMO.

Our --nopolicy patch doesn't use pseudopackages. We store that with the
parent package.

Regardless, the dummy package is bad because it's not only a hack but it's
one that the user has to worry about to install a package. Pseudopackages
may not be the best implementation of this (given your disdain for gpg key
pseudopackages), but they are at least a detail that the user doesn't have
to worry about. Splitting this out means that all users now have to worry
about this as well.

Thanks,
Chad Sellers




More information about the Rpm-maint mailing list