On 01/09/2014 12:01 AM, James Antill wrote:
On Wed, 2014-01-08 at 18:33 +0200, Panu Matilainen wrote:
My 5c is that the protected packages thing is a slippery slope that
easily leads to a false sense of security as there are TONNES of
"critical" packages which are not covered by defaults or the packages
themselves.
Two obvious things here:
1. Perfect is the enemy of good. Just because we can't automatically
know that if my-foo-pkg is removed your machine won't
boot/update/whatever _doesn't_ mean we can't be intelligent enough to
know that if the user removes the last version of glibc/rpm/yum that's
installed they better _really_ mean it.
It's not hard to solve 95%+ of the real world problems here, which
translates to countless people not thinking bad thoughts (or worse)
about you/dnf because their computer didn't get trashed.
2. The way the feature was designed is that any random package can put a
file in /etc/yum/protected.d with their package name in it. Thus. if
my-foo-pkg is a really important package to you then it's trivial to
change my-foo-pkg to have a file that protects itself, or use
puppet/etc. to do the same if you can't alter the package itself.
Probably wasn't clear from my message and the discussion is spread to so
many different places ... anyway, I've absolutely nothing against the
protected packages feature as such, on the contrary. The slippery slope
comes from the inconsistent manner of its usage in Fedora - systemd adds
itself to /etc/yum/protected.d but AFAICS nothing else does. Yum
defaults to protecting itself which covers a large area (glibc and all)
but if one starts leaning blindly to a safety rail which has large gaps
in it...
Midn you, I do not think it should be the job of the package manager to
somehow magically know which of the random gibberish names on a given
system running distro X version Y spin Z should be protected. But that's
where it gets tricky as one mans critical package is somebody elses
useless bloat, so except for a handful of special cases such as systemd
and glibc putting the data into packages themselves isn't necessarily
the best option. One possibility might be using critical-path-* groups
for populating protected packages but...
Also the notion of running tends to be at odds with package management
in various ways. There's zero protection against removing packages that
have instance(s) running. Lot of software will continue to function to
some extent, but eg firefox will start acting rather strange sooner or
later, and I wouldn't be surprised if eg libreoffice was the same.
This is also true, and instead of fixing it we just moved to "offline
updates" ... welcome to the new world where packaging is just a little
bit worse/worthless, forever.
For non-broken apps. something like "service condrestart" was used in
the "old world" and the kernel is kind of special from that point of
view in that it's the _hardest_ to restart without actually restarting
the computer.
What
if removing a package causes a running application to crash and lose
your full days work, do the users get to blame the package manager from
not protecting you from yourself?
I can guarantee they will, and I'd bet that a UI designer would
certainly argue that any package management GUI shouldn't be removing
running desktop apps. and that if it does it's a bug that should be
fixed.
Should yum/dnf/whatever refuse to
remove packages which are in use? Me thinks not, but that's the
direction the "but foo didn't protect me!" thinking leads...
If it could be easily (efficiently) implemented, and we didn't, I'm not
sure what we'd gain by not helping.
In the "perfect is the enemy of good"-line of thinking, I'd think just
walking /proc/*/exe would cover a fair distance without being hideously
expensive. OTOH its always going to be racy as the window from starting
a transaction from actually removing the file(s) can be quite lengthy,
and I dont see how that could be eliminated. Short of pushing things
offline (sigh...)
- Panu -
_______________________________________________
Yum-devel mailing list
Yum-devel@lists.baseurl.org
http://lists.baseurl.org/mailman/listinfo/yum-devel
