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
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201206011929.37302.hol...@layer-acht.org
