Bug#568313: Bug#673301: useless use of dpkg-statoverride

[Holger Levsen <holger@layer-acht.org>]

Hi Bertrand,

On Sonntag, 20. Mai 2012, Bertrand Marc wrote:
> I am trying to make up my mind about using or not dpkg-statoverride. The
> most useful info I found is in bug #568313 [1].

Indeed, thats a good discussion, which actually changed my mind a bit :)

> They seem to conclude 2
> things applying on our cases :
> 	- dpkg-statoverride --list must be used to check if the administrator
> allows dpkg to change permissions on the file. For instance an
> administrator could set an override before the installation and you
> don't want to mess with it.

indeed. So the only way to use dpkg-statoverride in maintainer scripts should 
be using --list, and then using simple chown/chmod, leaving other uses of 
dpkg-override to local admins only.

> 	- not using dpkg-statoverride might lead to unpredictable results
> between unpack and configure on upgrade. In gnunet, as the daemon is
> stopped before upgrades, only a malicious user could try to use the
> binaries to do something not allowed, but it doesn't seem dangerous to me.

Also this can be prevented by shipping with safe permissions (=non setuid/gid) 
and changing them in postinst....

> As a result, I don't know how it should be done, but I think policy
> should be more explicit about when to use dpkg-statoverride or not.
> 
> In his last message, Brandon concludes one "must" use dpkg-statoverride
> for dynamic uid/gid, but it is not that clear to me in Debian policy.

file a bug against policy?! Uppps, #568313 is just that, so cc:ing the bug. 
(Please take care when answering and only reply to one or the other!)


cheers,
	Holger