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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
