Hi Simon and Alan, On Fri, 16 Jun 2023 at 09:24, Simon McVittie wrote: > > 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.
/etc/odbcinst.ini should definitely be created during postinst if not already present. In this case, the log should show an error on preinst as well. > 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/1009152#15 is the > right thing to be doing here. I tested multiple new install and upgrade scenarios, although it seems likely I didn't test this particular scenario. There is no user impact, other than a slightly non-clean system. rm_conffile renames the conffile to conffile.dpkg-bak, which is only deleted during package purge. I'm now thinking a much better approach is to test for the presence of the backup file during postinst and copy it back as /etc/odbcinst.ini. That would greatly simplify things and avoid any breakage that we are seeing now. I'll test this thoroughly, of course. > 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. Yes, mktemp or tempdir would be more appropriate, although retrieving the path in a different script is not so easy.
