Control: retitle -1 dpkg: Please either keep or warn when taking over unowned paths Control: severity -1 wishlist Control: tags -1 - security Control: block -1 by 672608
On Sun, 2013-04-28 at 18:09:49 -0400, Filipus Klutiero wrote: > Package: dpkg > Version: 1.16.10 > Severity: important > Tags: security > Each Debian install uses a varying set of OS files to support the > OS. On a typical install, these OS files may claim from 50 to 150 K > paths. The set of dpkg-owned paths varies when a new package is > installed. Of course, a path dpkg wants to use for a new OS file may > already be in use. The paths used in Debian packages are all on paths reserved for the system, if admins use those to place local files, they are susceptible to have them taken over by dpkg. That's what /root, /home, /usr/local, /srv, /opt and other paths are for. > At least on this system, dpkg quietly overwrites pre-existing files > using paths conflicting with newly claimed paths. I am neither asked > how to procede nor even warned that non-OS files were overwritten. > Worst - overwritten files are apparently lost; I don't see any > location where they would have been moved. This is how dpkg has worked all this time, changing the current behaviour has wide ranging implications, should be considered very carefully and as such it's at most a wishlist (and I don't see how this has security implications at all...). Regarding the current behavior, for example switching a path from a configuration file to a conffile relies on this behavior, or any other maintainer script file that might later be shipped in the .deb. I don't think I'll consider changing this behavior, at least not until dpkg can track arbitrary files not shipped in .deb packages. > Oddly enough, dpkg can't overwrite files installing a new package if > the existing files are already owned by dpkg in another package. I don't see how this is odd... > dpkg has a check for that particular case, but not for the general > case. Checking against unowned paths is not the genric case of checking against the known paths. Regards, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
