Vital and critical configuration files get overridden by system updates without warning

[Dominik Wezel]

• In my /usr/share/X11/locale/en_US.UTF-8/Compose I have about 10'000 lines of special compose keys defined.
• In my /boot/grub/grub.cfg I have a very complicated special setup for my various boot configurations, and a 5-sec timout for my EFI-config.
• My /etc/ssh/sshd_config contains a well-balanced configuration

All these files are regularly overridden WITHOUT EVEN A SINGLE WARNING or ASKING BACK by ubuntu system setups (discover).

I set all of them to read-only by root and no-access for group and other users, but they still get overridden by every other system update. I even have a shutdown process in place which should actually make sure that changes to these files are reverted by writing a backup copy over any newly installed override — unfortunately, everything I did to run either a custom shutdown process or a startup process with systemd turned out to not work and be a nightmare to make work.

How somebody could be as bold as to override vital configuration files like this without even asking for consent is one of the strange miracles in this world which I'll probably never understand. However, if "ubuntu" is really what it translates to, it should take a little bit more care about pre-existing configurations on systems on which it is set up and running well — until one system update suddenly jeopardizes the functioning of the entire system. I'm pretty sure these are not the only configuration files which are carelessly just overridden. They're just the ones every other update breaks my system and inflinges on my the costs of hours of research until I find out that — of course — it was an overridden critical system configuration again. The really mean thing is that you don't notice anything when you run the update … only next time you start your system and of course are not aware anymore that you did a system update, the new (absolutely wrong and/or insufficent) settings are in place and shoot you in the leg.

Take an example from gentoo's etc-update feature which lets you merge new configuration files with pre-existing ones using a diff3-update. I went away from gentoo for other reasons, but I always praised that feature.

Please make sure immediately that critical configuration files do not get overridden if they are non-writable by root, and then gradually introduce a system that merges changes to configuration files with the current situation on the target system. Or at least present the configs that would be changed in a particular directory, so that anybody who is interested in preserving local settings could merge them in a suitable way.

Thanks

ProblemType: Bug
DistroRelease: Ubuntu 20.10
Package: xorg 1:7.7+19ubuntu15
ProcVersionSignature: Ubuntu 5.8.0-53.60-generic 5.8.18
Uname: Linux 5.8.0-53-generic x86_64
ApportVersion: 2.20.11-0ubuntu50.7
Architecture: amd64
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
CasperMD5CheckResult: skip
CompositorRunning: None
CurrentDesktop: KDE
Date: Thu May 27 18:48:15 2021
DistUpgraded: Fresh install
DistroCodename: groovy
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes
GraphicsCard:
 NVIDIA Corporation TU117GLM [Quadro T1000 Mobile] [10de:1fb9] (rev a1) (prog-if 00 [VGA controller])
   Subsystem: Lenovo TU117GLM [Quadro T1000 Mobile] [17aa:2297]
InstallationDate: Installed on 2021-01-15 (132 days ago)
InstallationMedia: Kubuntu 20.10 "Groovy Gorilla" - Release amd64 (20201022)
MachineType: LENOVO 20QQS0KL13
ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-5.8.0-53-generic root=UUID=35cef147-e021-4bdd-b8db-31a3192c8a6a ro rootflags=subvol=@ quiet splash vt.handoff=7
SourcePackage: xorg
Symptom: display
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 06/04/2020
dmi.bios.release: 1.23
dmi.bios.vendor: LENOVO
dmi.bios.version: N2NET38W (1.23 )
dmi.board.asset.tag: Not Available
dmi.board.name: 20QQS0KL13
dmi.board.vendor: LENOVO
dmi.board.version: SDK0J40697 WIN
dmi.chassis.asset.tag: ZF211710
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.ec.firmware.release: 1.14
dmi.modalias: dmi:bvnLENOVO:bvrN2NET38W(1.23):bd06/04/2020:br1.23:efr1.14:svnLENOVO:pn20QQS0KL13:pvrThinkPadP53:rvnLENOVO:rn20QQS0KL13:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone:
dmi.product.family: ThinkPad P53
dmi.product.name: 20QQS0KL13
dmi.product.sku: LENOVO_MT_20QQ_BU_Think_FM_ThinkPad P53
dmi.product.version: ThinkPad P53
dmi.sys.vendor: LENOVO
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.102-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 20.2.6-0ubuntu0.20.10.1
version.libgl1-mesa-glx: libgl1-mesa-glx N/A
version.xserver-xorg-core: xserver-xorg-core 2:1.20.9-2ubuntu1.3
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1ubuntu1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20200714-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

[Paride Legovini (paride)]

Hello Dominik and thanks for this bug report. An umbrella bug report doesn't really help here, especially given that there's no single "reset config files on updates" policy in Ubuntu. Actually it's quite the contrary: as a Debian derivative Ubuntu basically inherits [1] and in particular [2].

Please file individual bug reports against the affected packages, possibly providing steps to reproduce the problem. In the case of openssh-server I can say that the overwrite shouldn't happen, as ssh_config is handles via ucf [3]. But let's discuss this in a dedicated bug, once opened. I'll just add that the newer versions of openssh-server support dropping custom config snippets in /etc/ssh/sshd_config.d/, for easier handling of custom configurations.

Thanks!

[1] https://www.debian.org/doc/debian-policy/ch-files.html#configuration-files
[2] https://www.debian.org/doc/debian-policy/ch-files.html#behavior
[3] http://manpages.ubuntu.com/manpages/focal/man1/ucf.1.html

[Dominik Wezel (freedio)]

Hi Paride

Thanks for your feedback. I'm a bit confused and concerned that a critical behaviour like this has to be addressed on package level and is not part of aptitude, but so be it.

I will file individual bug reports against the affected packages when a configuration file is next overridden in this package, to avoid to address something that may have already been fixed (e.g. I couldn't say when the last time ssh was updated and sshd_config overridden, while Compose was overridden just recently, and grub.cfg gets overridden almost every time discovery runs).

Dominik

[Timo Aaltonen (tjaalton)]

libx11 owns it's files in /usr, users are not supposed to touch them

[Dominik Wezel (freedio)]

Making changes to /usr/share/X11/locale/en_US.UTF-8/Compose was, at least for some time, the only way to make keyboard composition work in Ubuntu, as ~/.XCompose didn't work anymore, and creating a custom keyboard layout from scratch was not an option (my XCompose contains key compositions for almost the entire non-JCK UniCode character set in XCompose-coding).

[Dimitri John Ledkov (xnox)]

/boot/grub/grub.cfg is a generated file that must not be modified by hand. Instead one is supposed to modify things like /etc/default/grub /etc/default/grub.d/* /etc/grub.d/*

[Dimitri John Ledkov (xnox)]

sshd_config is user modifyable and maintained. Some options can be changed using dpkg-reconfigure openssh-server but otherwise changes to it should be preserved.

Can you please provide steps to reproduce changes to sshd_config getting lost?

[Dominik Wezel (freedio)]

As to sshd_config:

I will, when the case arises again.

Unfortunately, I don't use sshd in my boxes on a regular basis and so often discover only changes that possibly happened a long time ago. I remember a nasty change from "PasswordAuthentication no" to "#PasswordAuthentication yes", but honestly it was quite some time ago.

[Dominik Wezel (freedio)]

As to grub.cfg:

I set GRUB_TIMEOUT=5 in my /etc/default/grub, but the timeout for efi was reset to 30 on every update. I didn't know that files in /etc/default/grub.d are supposed to be changed, but I now changed

if [ \$grub_platform = efi ]; then
  set timeout=${GRUB_RECORDFAIL_TIMEOUT:-30}
  if [ x\$feature_timeout_style = xy ] ; then
    set timeout_style=menu
  fi
fi

in /etc/grub.d/00_header to ... GRUB_RECORDFAIL_TIMEOUT:-5 ... and hope that this helps in the future.

[Julian Andres Klode (juliank)]

Please don't modify that in /etc/grub.d, set GRUB_RECORDFAIL_TIMEOUT=5 in the /etc/default/grub file (or in an /etc/default/grub.d snippet). /etc/grub.d file changes are last resort, that file changes and incorporating those changes with your own ones will be annoying.

[Launchpad Janitor (janitor)]

[Expired for openssh (Ubuntu) because there has been no activity for 60 days.]