FS#1126 - Pacman shouldn't remove critical packages with no user confimation
Attached to Project:
Pacman
Opened by Haakon Nilsen (haakon) - Wednesday, 14 July 2004, 18:03 GMT
Last edited by Judd Vinet (judd) - Wednesday, 14 July 2004, 18:51 GMT
Opened by Haakon Nilsen (haakon) - Wednesday, 14 July 2004, 18:03 GMT
Last edited by Judd Vinet (judd) - Wednesday, 14 July 2004, 18:51 GMT
|
Details
Using the command 'pacman -R pacman' will immediately make
pacman remove itself, requiring manual reinstallation of
pacman. This is of course a very stupid command to give, but
could happen to users who act very fast and think very
little (myself being the case in point).
The pacman package is of course not the only package that is critical. glibc and kernel26 would also not be good to remove in most cases, but I consider pacman especially vulnerable because it has no packages depending on it, so that 'pacman -R' will remove it with no user confirmation. This is also true for kernel26, but having removed that, you at least still have pacman available to reinstall it. Having discussed this issue at <URL:http://bbs.archlinux.org/viewtopic.php?t=5571>, people seem to agree that if you had something like this in /etc/pacman.conf: [options] HoldPkg = kernel glibc pacman ... pacman would then check this list before removing packages, and ask specifically for a confirmation if the user has issued a command to remove one of the packages "on hold". This way, no power is taken away from the user (every user should have the right to shoot himself in the foot if he wants to), while fast and thoughtless users have a level of protection against themselves. |
This task depends upon