my take on the protected packages problem

[Panu Matilainen]

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 -