Control: severity -1 wishlist Control: tags -1 - security Do not change these again.
On Mon, 2013-04-29 at 20:06:29 -0400, Filipus Klutiero wrote: > severity 706365 important > tags 706365 + security > On 2013-04-28 20:44, Guillem Jover wrote: > >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. No, this is clearly defined by the FHS, which Debian follows, any exception is listed in the Debian policy. And the FHS is extremely clear on what paths are the exclusive domain of the sysadmin (the ones I listed for example), and as such not touched by applications and similar. > 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. Because of the above, reporting or doing any other action when confronted with sysadmin error is a new feature request, and as such wishlist. > >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. Which still does not describe a situation with security implications. > 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). See above, user error → wishlist. > 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). Thanks for the lecture, but this is still a wishlist request. > > 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. Ehrm... > 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. Prompting at unpack time would be unacceptable, and currently such prompting might only be performed for conffiles, if at all. Any other files managed by maint scripts and switched to files shipped in the .deb file will be silently taken over. > >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). Wrong. Regards, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
