Score:0

Locally and durably remove some files of a Debian package

cn flag

Context: On Debian, when hardening PHP I disabled and deleted a few unused PHP modules: for example, for wddx I deleted:

  • /etc/php/7.3/*/conf.d/20-wddx.ini
  • /etc/php/7.3/mods-available/wddx.ini
  • /usr/share/php7.3-xml/xml/wddx.ini
  • /usr/lib/php/*/wddx.so

When I upgraded, the PHP modules reappeared in /usr/share/php7.3-xml/xml/wddx.ini and /usr/lib/php/*/wddx.so although dpkg correctly did not add the 'enabling' configuration in /etc (thanks for the maintainer or dpkg for checking this!):

Not replacing deleted config file /etc/php/7.3/mods-available/wddx.ini
WARNING: Module wddx ini file doesn't exist under /etc/php/7.3/mods-available

Question: Is there a way, perhaps with dpkg-divert or a local dpkg trigger, to tell dpkg not to write again some files or to delete them after they are written?


P.S.

  • multiple PHP modules are packaged in php7.3-xml, and I need one of them, so it’s not possible to remove the whole Debian package.
  • the attack surface is already highly lowered given the PHP modules are not enabled, it is a refinement to also delete the .so file, hindering a human attacker and perhaps defeating a dumb automated malware script, even with root rights – obviously it should only be a part of the global defense.
  • it is possible to manually delete these files after upgrades or use a configuration management tool (Ansible, Puppet, Docker…), the question is about an integrated way of doing it with dpkg.
Score:0
cn flag

I don't know a simple way to say to APT or DPKG or other packet manager "don't write some files here" because the manager works with packages and not uncompressed files.

If modules are disabled with phpdismod then they are not charged on memory, but I agree with you it's better to avoid them from the filesystem.

Maybe the better way is to use a script or ansible job to remove unecessary files. In any case, It's not on the packet manager side who the answer exists !

Score:0
br flag

You can use the --remove option to remove a divert that has been previously set up. For example:

sudo dpkg-divert --remove /usr/share/php7.3-xml/xml/wddx.ini

Keep in mind that dpkg-divert is a global mechanism that affects all packages that are installed on the system. If you want to control which files are modified by a specific package, you may need to use a different approach, such as using a local dpkg trigger.

In general you can use the dpkg-divert command to prevent dpkg from overwriting certain files during package installation or upgrades. This can be useful if you have customized certain configuration files and do not want them to be overwritten by package updates.

To use dpkg-divert, you can specify the file or directory that you want to divert, and specify a target location where the file should be placed instead. For example, to divert the /usr/share/php7.3-xml/xml/wddx.ini file to a different location, you can use the following command:

sudo dpkg-divert --divert /usr/share/php7.3-xml/xml/wddx.ini.dpkg-new --rename /usr/share/php7.3-xml/xml/wddx.ini

This will create a copy of the wddx.ini file with the name wddx.ini.dpkg-new, and any future updates to the wddx.ini file will be written to the .dpkg-new file instead.

Score:0
in flag

Generally apt does not replace configuration files that have been modified during updates. If you don't touch the config files of a package, they will be replaced with new versions, if you do change config files they will be left alone and the newer config version will be placed alongside with a .dpkg-dist extension.

So, if you want to make absolutely sure your configuration stays as it is just change the main config of the service so it doesn't use the -available/-enabled directories. They are provided for convenience for inexperienced users but not necessary, other distributions don't use such directories.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.