• Bug#1104616: Backporting trixie mini-httpd

    From Lloyd@21:1/5 to Alexandru Mihail on Sat May 10 18:50:01 2025
    Hi Alexandru, thanks for the reply!

    Will the binary package from testing work as-is on stable/oldstable? I am usually careful about pulling packages forward that didn't get a backport build because I assumed there were other dependencies that would break, perhaps on OpenSSL versions and
    other such things, but from your note it sounds like that may not be an issue after all?

    Building from source is another option.

    I fully understand on the time commitment.

    Thanks for stepping in as maintainer.

    Regards
    Lloyd




    Alexandru Mihail wrote:

    Hi,
    Thanks for using mini-httpd !

    Indeed, not logging CGI has security implications, for sure. However,
    the version of mini-httpd in buster/bullseye has a LOAD of other issues
    as well (multihosting bugs, a buffer overflow I believe, no systemd
    service, etc).
    That version predates me as a maintainer of this package.
    If I were to release a backport of mini-httpd to stable and/or
    oldstable, I would have to port all new patches and retest, since it
    would be of little help to create a whole release just for CGI logging. Sadly, I currently lack the manpower for this.

    I have to ask, is there any reason at all for you to not just use the
    current testing (12) release on stable/oldstable ? You would get lots
    of other benefits in addition to fixing your CGI issue (systemd with hardening, better logging in general, etc) That's what I already do in production with my setup. As Salvo said, this is not RC for trixie as
    these changes are already applied in time for the trixie freeze.

    I'll close this in a few days if nothing happens


    Have a good one,
    Alexandru

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lloyd@21:1/5 to Alexandru Mihail on Sun May 11 08:10:01 2025
    Alexandru Mihail wrote:

    Therefore, I recommend the source route and I'll give you all
    instructions, works on a fresh stable VM. Hope this solves your issue
    Lloyd :D (until perhaps you update to trixie when it comes out)

    Hi Alex - thanks for the helpful info and detailed instructions!

    I was able to easily build the package; but, the service would not
    start. Several hours later I was able to identify the root cause.

    Unfortunately, it appears I uncovered a new bug. :(

    I run mini-httpd in chroot mode. The new systemd unit file in the
    latest release explicitly blacklists chroot syscall via the @mount
    syscall filter group. I've provided a patch below. However, for
    clarity's sake I think it's best I resolve this bug and open a new
    one.

    Regards
    Lloyd

    --- mini-httpd.service.default
    +++ mini-httpd.service.modified
    @@ -14,7 +14,7 @@
    ProtectSystem=full
    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=~@clock @cpu-emulation @debug @module @obsolete @reboot @raw-io
    RestrictNamespaces=~uts ipc pid user cgroup
    ProtectKernelTunables=yes
    ProtectKernelModules=yes
    @@ -27,4 +27,4 @@
    LockPersonality=yes

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lloyd@21:1/5 to All on Sun May 11 23:30:01 2025
    Hi Alex

    P.S: Please rush to change bug severity to normal

    done

    (Perhaps if you have a bit of time you can help me
    confirm his problem too granted you're also on stable

    I don't think it's a bug, he forgot to enable the service.

    mini-httpd ships disabled by default, no? Seems like a good
    plan for security and consistent with other Debian packages.

    I just wanted to mention the patch provided in the new bug
    report is updated (and improved) than the one I posted here.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)