Bug#568313: Bug#673301: useless use of dpkg-statoverride
On Fri, 01 Jun 2012, Holger Levsen wrote:
> > 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.
You can insert an override when none is present without trampling the local
admin, but in that case, you might not be able to "autofix" it quietly later
if you get it wrong or the situation changes. It is not too bad: if it is
important enough to warrant a statoveride change, asking the user about it
in postinst no matter who set the statoverride is actually safer for
everyone involved.
> Also this can be prevented by shipping with safe permissions (=non setuid/gid)
> and changing them in postinst....
This is quite good enough, actually. In postinst, don't touch anything if
an statoverride exists (dpkg will have already applied the override), or
chown/chmod it manually when none exists.
When it is about an ephemeral directory (e.g. stuff in /run), you must use
the same logic in the postinst and the initscript (easy)... but I have no
idea how easy it would be, e.g., for native systemd.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: