Package: mini-httpd
Version: 1.30-12
Severity: serious
Tags: patch, trixie
If the chroot directive is specified in mini-httpd.conf,
the mini_httpd process is killed when launched by systemd:
systemd[1]: mini-httpd.service: Job 5848 mini-httpd.service/start finished,
result=done
systemd[1]: Started mini-httpd.service - mini_httpd server.
systemd[1]: mini-httpd.service: Child 12020 belongs to mini-httpd.service.
systemd[1]: mini-httpd.service: Main process exited, code=killed, status=31/SYS
systemd[1]: mini-httpd.service: Failed with result 'signal'.
systemd[1]: mini-httpd.service: Service will not restart (restart setting)
systemd[1]: mini-httpd.service: Changed running -> failed
systemd[1]: mini-httpd.service: Unit entered failed state.
systemd[1]: mini-httpd.service: Consumed 37ms CPU time.
systemd[1]: mini-httpd.service: Control group is empty.
Marked serious as this will break upgraded installs running in chroot.
Root cause appears to be systemd hardening merged in 1.30-10;
SystemCallFilter in the unit file is set to blacklist the @mount filter set.
Unfortunately, @mount includes the chroot syscall. The below patch explicitly
permits chroot. When the patch is applied, the service starts normally in
chroot.
--- mini-httpd.service.default
+++ mini-httpd.service.modified
@@ -15,6 +15,7 @@
CapabilityBoundingSet=~CAP_BPF CAP_LINUX_IMMUTABLE CAP_IPC_LOCK
CAP_SYS_TTY_CONFIG \
CAP_SYS_BOOT CAP_MAC_* CAP_SYS_NICE CAP_SYS_RESOURCE
CAP_SYS_PTRACE
SystemCallFilter=~@clock @cpu-emulation @debug @module @mount @obsolete
@reboot @raw-io
+SystemCallFilter=chroot
RestrictNamespaces=~uts ipc pid user cgroup
ProtectKernelTunables=yes
ProtectKernelModules=yes
@@ -27,4 +28,4 @@
LockPersonality=yes
