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.
