Bug 1111855

Solution proposed in bug 1049310 comment 29.

thank you!

To quote bug 1049310 comment 29:

> Here's a plan: provide "Protected Packages" plugin that would prevent any
> transaction that removes the running kernel from occurring and also do that
> for packages that mark themselves (via provides) as protected 

I do not think that having the protection hard-coded in the packages is the right place. This really needs to be admin-configurable, because different things need to be protected in different cases. We may also want to have different protected sets as part of the Fedora products -- in fact, this is highly desirable.

(In general, this is the same reason that the RPM "Groups" feature was long ago deprecated in favor of external "comps" -- this kind of meta information is better externally.)

I think that the mechanism as implemented by yum now (config files read from a protected.d directory) is just about ideal, and I hope a DNF plugin would follow the same.

(In reply to Matthew Miller from comment #3)
> To quote bug 1049310 comment 29:
> 
> > Here's a plan: provide "Protected Packages" plugin that would prevent any
> > transaction that removes the running kernel from occurring and also do that
> > for packages that mark themselves (via provides) as protected 
> 
> I do not think that having the protection hard-coded in the packages is the
> right place. This really needs to be admin-configurable, because different
> things need to be protected in different cases. We may also want to have
> different protected sets as part of the Fedora products -- in fact, this is
> highly desirable.
> 
> (In general, this is the same reason that the RPM "Groups" feature was long
> ago deprecated in favor of external "comps" -- this kind of meta information
> is better externally.)
> 
> I think that the mechanism as implemented by yum now (config files read from
> a protected.d directory) is just about ideal, and I hope a DNF plugin would
> follow the same.

FWIW I see two different features here. A list of protected packages that is set by Fedora products and a set of extra protected packages set by admin. Would it make sense to split the two requests?

If we really want to protect users, having the distribution list that easily modifiable by admin doesn't make much sense IMO.

(In reply to Jan Zeleny from comment #4)
> FWIW I see two different features here. A list of protected packages that is
> set by Fedora products and a set of extra protected packages set by admin.
> Would it make sense to split the two requests?

I can see that possibility. It happens that the current mechanism covers both, but there may be an even better approach.


For the Fedora products, I think it's reasonable to have a list that isn't meant to be modified. It may be that simply having the "required" packages required by the fedora-product-definition package would be sufficient (and no dnf protection required, although possibly a _separate_ plugin which would simply warn that removing the fedora-product-definition would make the system be "generic Fedora" rather than that particular product).

 
> If we really want to protect users, having the distribution list that easily
> modifiable by admin doesn't make much sense IMO.

In the use case for which the yum feature was originally developed, the users were grad students and faculty with root on their machines, and enough knowledge to be dangerous. The "admin" was lab or central IT sysadmins. I think this is still a reasonable use case. It can apply anywhere where the direct admin is not highly experienced.

For cases where there isn't a second tier of more expert users, we can provide reasonable defaults. (The basic idea initially was: protect enough that it's easy to put the system back with the tools on the system itself -- hence, no removing yum itself.)

> FWIW I see two different features here. A list of protected packages that is
> set by Fedora products and a set of extra protected packages set by admin.
> Would it make sense to split the two requests?
> 
> If we really want to protect users, having the distribution list that easily
> modifiable by admin doesn't make much sense IMO.

That's overthinking without a proper use case. Let's provide the basic functionality as I proposed, probably using /etc/yum/protected.d and then take it from there.

The described functionality is provided upstream by c83d057.

Pre-release documentation of the plugin is available at rtfd.org:

http://dnf-plugins-core.readthedocs.org/en/latest/protected_packages.html

dnf-plugins-core-0.1.1-2.fc20, dnf-0.5.3-1.fc20, hawkey-0.4.17-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/dnf-0.5.3-1.fc20,hawkey-0.4.17-1.fc20,dnf-plugins-core-0.1.1-2.fc20

Package dnf-plugins-core-0.1.1-2.fc20, dnf-0.5.3-1.fc20, hawkey-0.4.17-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dnf-plugins-core-0.1.1-2.fc20 dnf-0.5.3-1.fc20 hawkey-0.4.17-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-8167/dnf-0.5.3-1.fc20,hawkey-0.4.17-1.fc20,dnf-plugins-core-0.1.1-2.fc20
then log in and leave karma (feedback).

dnf-plugins-core-0.1.1-2.fc20, dnf-0.5.3-1.fc20, hawkey-0.4.17-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.