my take on the protected packages problem

[James Antill]

On Thu, 2014-01-09 at 10:37 +0200, Panu Matilainen wrote:

> 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.

 Probably because I opened a bug against systemd for them to add it,
it's very possible other packages would do the same if people opened
other bugs (hint :).

>  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.

 As long as you can boot and use the package manager, the package
shouldn't need to be protected. So I don't think there will be many grey
areas, at worst a user can still do:

  "yum remove --setopt=protected_packages=. foo"

> >>   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.

 Kind of. "yum ps all" will mostly tell you that, and takes about 1
second to run on my machine (although it currently always looks for
updates, so does a metadata sync.) ... which isn't terrible, but also
about 20% overhead for user confirm overhead (much less if you time the
entire transaction, for sure).
 The bigger problems are that:

1. A lot of the daemons listed are known to work (so big false positive
rate).

2. Most of the daemons listed will be running all the time, and yum
doesn't have any integrated offline updates.

3. None of the libraries are flagged and adding them would probably make
it a lot slower (could maybe just take the running apps. and disqualify
all their deps. from update too, which might be better/quicker).

4. One of the advantages of protected_packages is that it'd always be a
fairly small list of things that needed protection, but on a large
server you could have _very_ big process lists. So there are scaling
problems.

...but I'm not against it, and I could certainly see using it if it was
available.