Hi,

I noticed this in a piuparts failure of mock/experimental (#775118) and
found it embarassingly simple to reproduce it in sid:

# dpkg-statoverride --update --add root unknown 0755 /bin/false ; echo $?
0
# dpkg -i hello_2.9-2_amd64.deb
dpkg: unrecoverable fatal error, aborting:
 unknown group 'unknown' in statoverride file

package removal is still possible at this stage

unfortunately the current piuparts tests are not able to spot this
problem in sid (experimental) in all cases, I only caught this since the
sid2experimental test requires a bit special handling
(mock/experimental passed the piuparts install+remove test while leaving
a "corrupted" statoverride file since there is no prerm/postrm to clean
up the statoverride)

* packages in testing are all clean (would be found by testing2sid)
  (or generally all releases due to release2successorrelease - the base
  system always changes)
* packages in sid should be caught if the package has some rdepends
  (would be noticed while testing the rdepends)
* (this only holds for cases where the package is not blocked from
  testing by transitive errors elsewhere)

i.e. the bug could be present in sid (experimental) in leaf packages

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


Andreas

Note that piuparts could run "dpkg --audit" (and possibly also "dpkg
--verify" to detect modified files) at the end.

I haven't double checked, but it seems likely that dpkg will load its
statoverride database in those operations and that you would thus detect
those problems.

Commit e4d6db177fad401ddc8432cf0e2c64e4fcf7bc0d
after https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=563307 introduced
a "lax parsing" mode that is only used in dpkg-statoverride
leaving dpkg in normal (strict) mode.

So I don't think that this bug deserves an RC status since the user can
drop the bad statoverride with a simple dpkg-statoverride invocation.

The RC bug, if any, ought to be on the package which calls
dpkg-statoverride incorrectly (or drop the user/group while it's now
widely agreed that we should not drop them) (and in general this is a tool
for administrators and not for package maintainers so it's doubly
wrong in most cases).

Cheers,

Hi!

Hmm, this one is tricky. I've lowered to serious because it can be
recovered by either removing the package or removing the statoverride.

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

Hi!

I'm only going to be fixing this for 1.17.x, as this is a regression.
The next items…

… are just nice to have, so will be leaving for 1.18.x. And the other
big issue…

… 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