Control: clone -1 -2 Control: severity -2 normal Control: retitle -2 dpkg: Does not react well to statdb getting out-of-sync w/ system passwd db
Hi! On Mon, 2015-01-12 at 12:30:11 +0100, Guillem Jover wrote: > Control: severity -1 serious > 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. I'm only going to be fixing this for 1.17.x, as this is a regression. The next items… > * 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. … are just nice to have, so will be leaving for 1.18.x. And the other big issue… > 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. … I've been thinking about, and I'll be implementing in 1.18.x tracking uid/gid alongside uname/gname, in case the uname/gname do not exist use the stored uid/gid, if they are out-of-sync, resync the db. But that requires db changes and code and string changes probably not suitable for the freeze and because this has always been the case, and although a very much suboptimal behavior I don't think this part should be considered RC. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
