Bug 1111855 - DNF needs to protect the basesystem
DNF needs to protect the basesystem
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: dnf-plugins-core (Show other bugs)
rawhide
All Linux
unspecified Severity high
: ---
: ---
Assigned To: Ales Kozumplik
Fedora Extras Quality Assurance
:
Depends On: 1067156
Blocks:
  Show dependency treegraph
 
Reported: 2014-06-21 15:09 EDT by Harald Reindl
Modified: 2014-07-08 22:30 EDT (History)
7 users (show)

See Also:
Fixed In Version: dnf-plugins-core-0.1.1-2.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-07-08 22:30:09 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Harald Reindl 2014-06-21 15:09:39 EDT
"coreutils" protects from destory the OS

[root@rawhide ~]# rm -rf /
/usr/bin/rm: it is dangerous to operate recursively on '/'
/usr/bin/rm: use --no-preserve-root to override this failsafe
______________________________________________________________________

yum remove pcre\*
Error: Trying to remove "systemd", which is protected
Error: Trying to remove "yum", which is protected

[root@rawhide ~]# yum remove kernel
Skipping the running kernel: kernel-core-3.16.0-0.rc1.git4.1.fc21.x86_64
______________________________________________________________________

dnf remove pcre\*: kills the system
dnf remove kernel: renders the system ubbootable
dnf remove rpm\*: kills the package management
______________________________________________________________________

this is a unacceptable regression and if Fedora would have a repsonsible QA it would be forbidden to propose DNF replacing YUM until such major regressions are not fixed
Comment 1 Ales Kozumplik 2014-06-23 05:08:20 EDT
Solution proposed in bug 1049310 comment 29.
Comment 2 Harald Reindl 2014-06-23 05:34:52 EDT
thank you!
Comment 3 Matthew Miller 2014-06-24 09:21:26 EDT
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.
Comment 4 Jan Zeleny 2014-06-24 10:52:43 EDT
(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.
Comment 5 Matthew Miller 2014-06-24 11:54:25 EDT
(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.)
Comment 6 Ales Kozumplik 2014-06-26 01:53:45 EDT
> 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.
Comment 7 Ales Kozumplik 2014-07-02 05:30:24 EDT
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
Comment 8 Fedora Update System 2014-07-07 05:11:54 EDT
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
Comment 9 Fedora Update System 2014-07-07 21:04:16 EDT
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).
Comment 10 Fedora Update System 2014-07-08 22:30:09 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.