Hi folks,
I found now that the setup rpm is removable from the system, which leads to unusable system, because of missing important files, like /etc/shadow, ....
Could you anyone say why that? I heard something about dependency hell, so in that case, the packages should be at least protected like dnf, systemd, etc.
One possible way would be the config file for dnf in downstream, like echo setup > /etc/yum/protected.d/setup.conf
Any better idea before I create bugzilla?
On Fri, Aug 18, 2017 at 7:43 AM, Petr Stodulka pstodulk@redhat.com wrote:
Hi folks,
I found now that the setup rpm is removable from the system, which leads to unusable system, because of missing important files, like /etc/shadow, ....
Could you anyone say why that? I heard something about dependency hell, so in that case, the packages should be at least protected like dnf, systemd, etc.
One possible way would be the config file for dnf in downstream, like echo setup > /etc/yum/protected.d/setup.conf
Any better idea before I create bugzilla?
Don't we have a basesystem package or something to mark as protected? It should be protected, so that people can't rip it out and bust the system into tiny little pieces.
On 18.8.2017 13:46, Neal Gompa wrote:
On Fri, Aug 18, 2017 at 7:43 AM, Petr Stodulka pstodulk@redhat.com wrote:
Hi folks,
I found now that the setup rpm is removable from the system, which leads to unusable system, because of missing important files, like /etc/shadow, ....
Could you anyone say why that? I heard something about dependency hell, so in that case, the packages should be at least protected like dnf, systemd, etc.
One possible way would be the config file for dnf in downstream, like echo setup > /etc/yum/protected.d/setup.conf
Any better idea before I create bugzilla?
Don't we have a basesystem package or something to mark as protected? It should be protected, so that people can't rip it out and bust the system into tiny little pieces.
We have. But currently I am able to remove that package without troubles because there is set just Requires(pres) for setup and filesystem. I heard something that circle dependency problem was there.
On Fri, 18 Aug 2017 13:43:28 +0200, Petr Stodulka wrote:
Hi folks,
I found now that the setup rpm is removable from the system,
Clarify, please. What exactly have you found out? Have you found an update case where one of the package updater tools removed it actually?
$ rpm -q --whatrequires setup rpcbind-0.2.4-7.rc2.fc26.x86_64 shadow-utils-4.3.1-3.fc26.x86_64
Whatever you've done, you would need to remove more packages before you could remove "setup".
In case a tool like "dnf" has done it, I'd like to see the details, particularly the packages DNF used to replace setup and shadow-utils.
which leads to unusable system, because of missing important files, like /etc/shadow, ....
Could you anyone say why that? I heard something about dependency hell, so in that case, the packages should be at least protected like dnf, systemd, etc.
One possible way would be the config file for dnf in downstream, like echo setup > /etc/yum/protected.d/setup.conf
Any better idea before I create bugzilla?
On Fri, Aug 18, 2017 at 7:55 AM, Michael Schwendt mschwendt@gmail.com wrote:
On Fri, 18 Aug 2017 13:43:28 +0200, Petr Stodulka wrote:
Hi folks,
I found now that the setup rpm is removable from the system,
Clarify, please. What exactly have you found out? Have you found an update case where one of the package updater tools removed it actually?
$ rpm -q --whatrequires setup rpcbind-0.2.4-7.rc2.fc26.x86_64 shadow-utils-4.3.1-3.fc26.x86_64
Whatever you've done, you would need to remove more packages before you could remove "setup".
In case a tool like "dnf" has done it, I'd like to see the details, particularly the packages DNF used to replace setup and shadow-utils.
It doesn't replace it with anything, it just considers it okay to remove from the system, because we don't have any protected packages that depend on setup. Technically, the basesystem package is supposed to be protected, but it's not. If it was, then setup would not be removable.
In Mageia, we have a package "mageia-dnf-conf" that adds additional protected.d files for protecting core system components. We probably need the same thing for Fedora.
On Fri, 18 Aug 2017 08:10:16 -0400, Neal Gompa wrote:
On Fri, Aug 18, 2017 at 7:55 AM, Michael Schwendt wrote:
On Fri, 18 Aug 2017 13:43:28 +0200, Petr Stodulka wrote:
Hi folks,
I found now that the setup rpm is removable from the system,
Clarify, please. What exactly have you found out? Have you found an update case where one of the package updater tools removed it actually?
$ rpm -q --whatrequires setup rpcbind-0.2.4-7.rc2.fc26.x86_64 shadow-utils-4.3.1-3.fc26.x86_64
Whatever you've done, you would need to remove more packages before you could remove "setup".
In case a tool like "dnf" has done it, I'd like to see the details, particularly the packages DNF used to replace setup and shadow-utils.
It doesn't replace it with anything, it just considers it okay to remove from the system, because we don't have any protected packages that depend on setup.
That doesn't make sense [yet]. It cannot remove it without breaking existing dependencies. It would need to remove shadow-utils, too, for example.
On 18.8.2017 14:18, Michael Schwendt wrote:
On Fri, 18 Aug 2017 08:10:16 -0400, Neal Gompa wrote:
On Fri, Aug 18, 2017 at 7:55 AM, Michael Schwendt wrote:
On Fri, 18 Aug 2017 13:43:28 +0200, Petr Stodulka wrote:
Hi folks,
I found now that the setup rpm is removable from the system,
Clarify, please. What exactly have you found out? Have you found an update case where one of the package updater tools removed it actually?
$ rpm -q --whatrequires setup rpcbind-0.2.4-7.rc2.fc26.x86_64 shadow-utils-4.3.1-3.fc26.x86_64
# dnf remove setup
I am not talking about update, I am talking about situation that you can break completely your system by removing of packages, that should not be removable. The logic why someone would want to remove such packages it is not relevant here. You shouldn't be able to do that. That's the point.
Whatever you've done, you would need to remove more packages before you could remove "setup".
In case a tool like "dnf" has done it, I'd like to see the details, particularly the packages DNF used to replace setup and shadow-utils.
It doesn't replace it with anything, it just considers it okay to remove from the system, because we don't have any protected packages that depend on setup.
That doesn't make sense [yet]. It cannot remove it without breaking existing dependencies. It would need to remove shadow-utils, too, for example.
Obiously you are able to remove shadow-utils "without troubles" too. That's just point that the list of protected packages should be bigger. IMHO, packages that are crucial for basic run of the system shouldn't be removable.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Fri, Aug 18, 2017 at 9:20 AM, Petr Stodulka pstodulk@redhat.com wrote:
On 18.8.2017 14:18, Michael Schwendt wrote:
On Fri, 18 Aug 2017 08:10:16 -0400, Neal Gompa wrote:
On Fri, Aug 18, 2017 at 7:55 AM, Michael Schwendt wrote:
On Fri, 18 Aug 2017 13:43:28 +0200, Petr Stodulka wrote:
Hi folks,
I found now that the setup rpm is removable from the system,
Clarify, please. What exactly have you found out? Have you found an update case where one of the package updater tools removed it actually?
$ rpm -q --whatrequires setup rpcbind-0.2.4-7.rc2.fc26.x86_64 shadow-utils-4.3.1-3.fc26.x86_64
# dnf remove setup
I am not talking about update, I am talking about situation that you can break completely your system by removing of packages, that should not be removable. The logic why someone would want to remove such packages it is not relevant here. You shouldn't be able to do that. That's the point.
Whatever you've done, you would need to remove more packages before you could remove "setup".
In case a tool like "dnf" has done it, I'd like to see the details, particularly the packages DNF used to replace setup and shadow-utils.
It doesn't replace it with anything, it just considers it okay to remove from the system, because we don't have any protected packages that depend on setup.
That doesn't make sense [yet]. It cannot remove it without breaking existing dependencies. It would need to remove shadow-utils, too, for example.
Obiously you are able to remove shadow-utils "without troubles" too. That's just point that the list of protected packages should be bigger. IMHO, packages that are crucial for basic run of the system shouldn't be removable.
Our basesystem package seems to be quite neglected.
For comparison, here's Mageia's basesystem: http://svnweb.mageia.org/packages/cauldron/basesystem/current/SPECS/basesyst...
We should probably consider filling out the basesystem package more and making it so that it is a protected package.
That package isn't supposed to get removed on a Fedora system anyway.
Neal Gompa wrote:
For comparison, here's Mageia's basesystem: http://svnweb.mageia.org/packages/cauldron/basesystem/current/SPECS/basesyst...
Huh? The full vim as a dependency of basesystem? I can see the case for vim-minimal (though in principle really any text-mode editor should do), but all of vim?
Kevin Kofler
On Fri, 18 Aug 2017 15:20:55 +0200, Petr Stodulka wrote:
$ rpm -q --whatrequires setup rpcbind-0.2.4-7.rc2.fc26.x86_64 shadow-utils-4.3.1-3.fc26.x86_64
# dnf remove setup
I am not talking about update, I am talking about situation that you can break completely your system by removing of packages, that should not be removable. The logic why someone would want to remove such packages it is not relevant here. You shouldn't be able to do that. That's the point.
Do you want to protect packages also against removing them with "rpm"?
On 18.8.2017 16:16, Michael Schwendt wrote:
On Fri, 18 Aug 2017 15:20:55 +0200, Petr Stodulka wrote:
$ rpm -q --whatrequires setup rpcbind-0.2.4-7.rc2.fc26.x86_64 shadow-utils-4.3.1-3.fc26.x86_64
# dnf remove setup
I am not talking about update, I am talking about situation that you can break completely your system by removing of packages, that should not be removable. The logic why someone would want to remove such packages it is not relevant here. You shouldn't be able to do that. That's the point.
Do you want to protect packages also against removing them with "rpm"? _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Hmmm, is it possible? I thought that with rpm I am able to remove even protected packages. In addition, I am able to remove even packages without dependencies, so I don't see the point. rpm is low level tool. No, I am talking just about use of dnf which is high level tool for working with packages/modules.
On Fri, 18 Aug 2017 17:03:57 +0200, Petr Stodulka wrote:
# dnf remove setup
rpm is low level tool. No, I am talking just about use of dnf which is high level tool for working with packages/modules.
*ouch* Covering such a corner-case is of limited use, IMO. What other package tools would benefit from such a protection?
If, on the contrary, dnf decided to remove such packages during a normal updates while running into depsolving troubles, _that_ would be interesting to fix (because removing a package without replacing it would be a big bug).
On 18.8.2017 17:24, Michael Schwendt wrote:
On Fri, 18 Aug 2017 17:03:57 +0200, Petr Stodulka wrote:
# dnf remove setup
rpm is low level tool. No, I am talking just about use of dnf which is high level tool for working with packages/modules.
*ouch* Covering such a corner-case is of limited use, IMO. What other package tools would benefit from such a protection?
It's corner case, but user is user. We could say same thing about udev, systemd, dnf... Why these are protected? Who would want to remove it from the system, when they know such operation will break system significantly? The protection has some purpose and for me is not relevant, how much is possible, that someone would do that improbably action. I saw many situations that were *impossible*, but user can do everything. So the elementary set of packages should be protected.
If, on the contrary, dnf decided to remove such packages during a normal updates while running into depsolving troubles, _that_ would be interesting to fix (because removing a package without replacing it would be a big bug). _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Mon, 21 Aug 2017 10:07:48 +0200, Petr Stodulka wrote:
*ouch* Covering such a corner-case is of limited use, IMO. What other package tools would benefit from such a protection?
It's corner case, but user is user. We could say same thing about udev, systemd, dnf... Why these are protected? Who would want to remove it from the system, when they know such operation will break system significantly? The protection has some purpose and for me is not relevant, how much is possible, that someone would do that improbably action. I saw many situations that were *impossible*, but user can do everything. So the elementary set of packages should be protected.
Many "elementary" packages are not protected, and their removal can break a system in various ways. Adding protections to Yum/DNF config gives a false sense of security.
On Mon, Aug 21, 2017 at 11:03:24AM +0200, Michael Schwendt wrote:
Many "elementary" packages are not protected, and their removal can break a system in various ways. Adding protections to Yum/DNF config gives a false sense of security.
The original intention was to at least ensure that you couldn't easily and accidentally put your system into a state where you couldn't put it back with the same tools you used to break it. (That is, don't let yum remove things yum needs to install stuff, basically.)
I think there's use in extending it a *little* beyond that, but I also don't think we should go overboard.
On 21 August 2017 at 12:19, Matthew Miller mattdm@fedoraproject.org wrote:
The original intention was to at least ensure that you couldn't easily and accidentally put your system into a state where you couldn't put it back with the same tools you used to break it.
Does that include using tools like rm as root or just ones like rpm? If the user has got root access and is able to remove random core packages (also agreeing to a huge list if scary looking dependencies) then perhaps that user shouldn't have admin access to a system...
Richard.
On Mon, Aug 21, 2017 at 02:40:40PM +0100, Richard Hughes wrote:
The original intention was to at least ensure that you couldn't easily and accidentally put your system into a state where you couldn't put it back with the same tools you used to break it.
Does that include using tools like rm as root or just ones like rpm?
Of course not. And, for that matter, not _even_ rpm. (For this reason, I think using the protected-packages functionality is better than adding package deps for this purpose.
If the user has got root access and is able to remove random core packages (also agreeing to a huge list if scary looking dependencies) then perhaps that user shouldn't have admin access to a system...
It's really easy to miss something in a huge list. Or to not understand the ramifications of something in a small list, and then regret it.
On Fri, Aug 18, 2017, at 07:43 AM, Petr Stodulka wrote:
Hi folks,
I found now that the setup rpm is removable from the system, which leads to unusable system, because of missing important files, like /etc/shadow, ....
Sounds like you're using dnf for a host system? The Fedora editions that use rpm-ostree for the host (Atomic Host, and https://pagure.io/workstation-ostree-config) are quite resilient to this; in fact by default package layering is just that - layering, it doesn't allow removing from the base.
But while rpm-ostree has somewhat of a (partially deserved) reputation for "you can't do that", in fact you can:
# rpm-ostree status State: idle ● fedora-atomic:fedora/26/x86_64/atomic-host Version: 26.101 (2017-08-06 21:27:14) Commit: f6331bcd14577e0ee43db3ba5a44e0f63f74a86e3955604c20542df0b7ad8ad6 GPGSignature: Valid signature by E641850B77DF435378D1D7E2812A6B4B64DAB85D # rpm-ostree ex override remove setup ... Resolving dependencies... failed error: The following base packages would be removed: atomic-1.18.1-5.fc26.x86_64, atomic-devmode-0.3.7-1.fc26.noarch, cloud-init-0.7.9-7.fc26.noarch, cockpit-docker-147-1.fc26.x86_64, cockpit-networkmanager-147-1.fc26.noarch, cockpit-ostree-147-1.fc26.x86_64, cockpit-system-147-1.fc26.noarch, nfs-utils-1:2.1.1-5.rc5.fc26.x86_64, rpcbind-0.2.4-7.rc2.fc26.x86_64, shadow-utils-2:4.3.1-3.fc26.x86_64
But let's say that's not scary enough and I really, really want to try 😉
# rpm-ostree ex override remove setup atomic atomic-devmode cloud-init cockpit-{docker,networkmanager,ostree,system} nfs-utils rpcbind shadow-utils ... Transaction complete; bootconfig swap: yes deployment count change: 1 ... Run "systemctl reboot" to start a reboot # rpm-ostree status State: idle Deployments: fedora-atomic:fedora/26/x86_64/atomic-host Version: 26.101 (2017-08-06 21:27:14) BaseCommit: f6331bcd14577e0ee43db3ba5a44e0f63f74a86e3955604c20542df0b7ad8ad6 GPGSignature: Valid signature by E641850B77DF435378D1D7E2812A6B4B64DAB85D RemovedBasePackages: atomic-1.18.1-5.fc26.x86_64, cloud-init-0.7.9-7.fc26.noarch, shadow-utils-2:4.3.1-3.fc26.x86_64, rpcbind-0.2.4-7.rc2.fc26.x86_64, cockpit-system-147-1.fc26.noarch, nfs-utils-1:2.1.1-5.rc5.fc26.x86_64, cockpit-networkmanager-147-1.fc26.noarch, cockpit-docker-147-1.fc26.x86_64, setup-2.10.5-2.fc26.noarch, atomic-devmode-0.3.7-1.fc26.noarch, cockpit-ostree-147-1.fc26.x86_64
● fedora-atomic:fedora/26/x86_64/atomic-host Version: 26.101 (2017-08-06 21:27:14) Commit: f6331bcd14577e0ee43db3ba5a44e0f63f74a86e3955604c20542df0b7ad8ad6 GPGSignature: Valid signature by E641850B77DF435378D1D7E2812A6B4B64DAB85D #
But of course by design, the override remove packages are still available in the base tree; your current system was untouched, and if you choose to reboot and something went wrong, you'll have the rollback. And regardless, undoing the override is always possible, without redownloading anything (which would obviously not be easily possible here since I removed NetworkManager):
# rpm-ostree ex override reset setup atomic atomic-devmode cloud-init cockpit-{docker,networkmanager,ostree,system} nfs-utils rpcbind shadow-utils
Will get back to the base.
Dne 18.8.2017 v 13:43 Petr Stodulka napsal(a):
which leads to unusable system, because of missing important files, like /etc/shadow, ....
Lets just focus on this one package. The question is why the removal of the package is removing /etc/shadow /etc/passwd ?
When I remove it it will: warning: /etc/shadow saved as /etc/shadow.rpmsave warning: /etc/passwd saved as /etc/passwd.rpmsave
That is because there is in spec file:
%verify(not md5 size mtime) %config(noreplace) /etc/passwd %verify(not md5 size mtime) %config(noreplace) /etc/group
I would expect rather %ghost directive there.
With %ghost in place we can even omit the %posttrans:
#throw away useless and dangerous update stuff until rpm will be able to #handle it ( http://rpm.org/ticket/6 ) %post -p <lua> for i, name in ipairs({"passwd", "shadow", "group", "gshadow"}) do os.remove("/etc/"..name..".rpmnew") end
The initial content should be IMHO populated by anaconda.
With the %ghost the removal of package will leave the important files on disk and the system will be operational.
Mirek