Control: severity -1 serious Hi!
On Sun, 2015-01-11 at 20:23:27 +0100, Andreas Beckmann wrote: > Package: dpkg > Version: 1.17.23 > Severity: grave > Justification: renders dpkg -i unusable Hmm, this one is tricky. I've lowered to serious because it can be recovered by either removing the package or removing the statoverride. > another case where a "corruption" could be left after removal is > > * preinst/postinst creates a user and a statoverride > * prerm/postrm removes the user but leaves the statoverride > => statoverride file will be "corrupted" only after removal (purge?) of > the buggy package > > these wouldn't be caught by piuparts since there is no more package > installation after purge > > dpkg-statoverride clearly should refuse unknown groups (havent checked > what happens with unknown user or other bad arguments) instead of > creating a "corrupted" database So, there's several sides to this bug: * dpkg-statoverride, should indeed refuse to add entries for unknown user/group, I'm fixing this. * even on lax parsing, it should warn on unknown user/group, I'm also fixing this. * it would be nice to have a dpkg-statoverride --check/--audit/--verify that performs several sanity checks on the statoverride db against the system, I'll be implementing something along those lines for 1.18.x. This still leaves a window where a package can break the system for other packages, and where it disallows to fix the problem with an upgrade which is the usual way to fix such issues, when the user gets removed from the system but the statoverride remains, which is not acceptable for dpkg to get into. :/ I'll ponder about possibly allowing dpkg to operate anyway, but disabling that specific statoverride or similar, to allow such case if the overridden path does not exist, or to always track uid/gid and use those in case the uname/gname do not exist, because that might be better than an outright abort. This type of situation will also be relevant when tracking path metadata, with user/group information, because the dpkg db can get out of sync with the system as well. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
