Bug#203650: Poor recommendation in dpkg-statoverride section

[Adam Heath <doogie@debian.org>]

On Thu, 31 Jul 2003, Andrew Suffield wrote:

> Here's the current text of the latter part of section 10.9.1:
>
> ============
> Given the above, dpkg-statoverride is essentially a tool for system
> administrators and would not normally be needed in the maintainer
> scripts. There is one type of situation, though, where calls to
> dpkg-statoverride would be needed in the maintainer scripts, and that
> involves packages which use dynamically allocated user or group
> ids. In such a situation, something like the following idiom can be
> very helpful in the package's postinst, where sysuser is a dynamically
> allocated id:
>
>      for i in /usr/bin/foo /usr/sbin/bar
>      do
>        if ! dpkg-statoverride --list $i >/dev/null
>        then
>          dpkg-statoverride --update --add sysuser root 4755 $i
>        fi
>      done
>
> The corresponding dpkg-statoverride --remove calls can then be made
> unconditionally when the package is purged.
> ============

Note that without --update, dpkg-statoverride will *not* change the perms of
existing files on disk.  This should be emphasized in any example given for
usage.

> This means that the files are unpacked with whatever permissions were
> in the package, and are then modified during postinst. In addition, if
> the sysadmin removes the statoverride entry, the postinst will blindly
> add it back again later.
>
> So, let's break down what happens a bit:
>
>  - dpkg unpacks the files, with their original permissions
>  - postinst creates a user
>  - postinst adds a statoverride to change the permissions
>
> The "problem" is that the user doesn't exist until after you unpack
> the files. Adding a statoverride here is a somewhat strange approach
> in its own right, ignoring such matters as the period between unpack
> and configure when permissions/owners are wrong.
>
> I suggest that this sequence would make more sense:
>
>  - preinst creates a user
>  - dpkg unpacks the files

This implies that the deb would have the name of the dynamic user for the
files.  However, creating such a deb is problematic, as the build system will
most likely not have the user.

Extending adduser to tell faked(from fakeroot) to map dynamic users seems
fugly to me, and doesn't handle the case when sudo(or just plain root) is
used.

However, perhaps having fakeroot divert adduser, and when adduser is then run
under fakeroot, a fakeroot-specific version would be used, that would
communicate with faked, would be better.

There may still need to be a call to dpkg-statoverride, but it would be in the
preinst.