Control: severity -1 serious Control: block 1038041 by -1 On Fri, 16 Jun 2023 at 03:49:12 +0930, Arthur Marsh wrote: > Attempting to upgrade odbc related packages from 2.3.11-2 to 2.3.11-3
> Setting up unixodbc-common (2.3.11-3) ... > cp: cannot stat '/tmp/odbcinst.ini.bak': No such file or directory > dpkg: error processing package unixodbc-common (--configure): > installed unixodbc-common package post-installation script subprocess > returned error exit status 1 Here's a repeatable reproducer for this bug: $ podman run --rm -it debian:sid # not sid-slim to avoid #1038067 # apt update # apt upgrade # apt install unixodbc-common # rm /etc/odbcinst.ini # apt install --reinstall unixodbc-common ... Unpacking unixodbc-common (2.3.11-3) over (2.3.11-3) ... Setting up unixodbc-common (2.3.11-3) ... cp: cannot stat '/tmp/odbcinst.ini.bak': No such file or directory I don't actively use this package (it's installed as a dependency) so I haven't *intentionally* modified or deleted /etc/odbcinst.ini, but it wasn't present on my laptop for whatever reason, causing this failure mode during upgrades. Deleting configuration files is usually treated as an intentional sysadmin change that should be preserved. I think the regression of failing to upgrade is a considerably worse bug than the old conffile record still being present in dpkg's database (#1009152). Is there a user-visible impact of #1009152 that makes it worth having this extra complexity? I'm not at all sure that https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009152#15 is the right thing to be doing here. Not *directly* related to the failure to upgrade, but I'm also concerned by this package using a fixed filename in /tmp to save and restore a root-owned configuration file. /tmp is world-writeable, so the worst-case assumption needs to be that a malicious local user has created /tmp/odbcinst.ini.bak with crafted contents (maybe as a directory, or a symlink to a location of their choice, or as a hard link). If so, then I'm worried that there might be something they can do to cause a denial of service, or worse, overwrite something (/etc/odbcinst.ini or otherwise) with attacker-controlled contents. If this tricky save/restore transaction is needed, it would be safer to use a root-owned location in /etc or /var that is namespaced appropriately for the package, for example perhaps "/etc/odbcinst.ini.maintscript-temp" analogous to dpkg's .dpkg-old and so on. smcv
