severity 706365 important
tags 706365 + security
thanks
Hi Guillem,
On 2013-04-28 20:44, Guillem Jover wrote:
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.
I agree that in a sense even paths of files in non-installed packages are
reserved for the OS. But in practice, system admins don't know what these paths
are. And even if they would do, the set of reserved paths keeps growing with
each Debian version, so a system admin can claim a non-reserved path on a
certain Debian version and the path can be taken over at the next upgrade.
In any case, the problem reported here is not dpkg taking over paths - it's
dpkg /quietly/ (and brutally) overwriting files in newly claimed paths.
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...).
The security implications come from the brutal overwriting of files without
warning. This can cause various problems such as service disruptions. Most
importantly, as these can be local files and the overwriting is done without
backups, this can cause data loss, hence severity important (at least).
The ITS's Severity field indicates whether a ticket is a bug report or a mere
request for enhancement, and in the case of bug reports, the reported bug's
importance. Priority (or difficulty) is not a factor in a ticket's severity
(see #704874 for more information).
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'm not well aware of how such a switch happens, but I don't see a great
blocker here. Such a switch must already require prompting, unless the file is
left intact, in which case we need not to prompt any more than we currently do.
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.
No, checking that paths are unused is the generic case of checking that paths
are not used by the OS. It is odd that we have no check for the generic case,
while we have not 1 but 2 mechanisms to check for the specific case of
conflicts in OS files (conflicts declarations and an installed OS files
database).
