severity 706365 important
tags 706365 + security
thanks
On 2013-04-30 01:37, Guillem Jover wrote:
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.
The FHS does not define the directories above as the exclusive domain of the
sysadmin. Even if it did, the vast majority of Debian installs do not have a
filesystem hierarchy policy anyway, and even those that do are unlikely to have
a policy any more FHS-compliant than the Debian project's.
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 ticket is not asking to do anything when confronted with sysadmin error,
just in the cases reported.
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.
Then you might want to read the following paragraph, but integrity and
confidentiality are not the only aspects of security.
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.
Thanks for your opinion, but a misbehavior from dpkg is a bug, not /merely/ a
request for enhancement as implied by the /wishlist/ severity.
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 see why prompting would be unacceptable, otherwise that's pretty much
the problem reported here.
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.
If you think something quoted is wrong, you're free to explain what makes you
think so.
