Your message dated Wed, 17 Mar 2021 22:10:58 +0100 with message-id <1616015372@msgid.manchmal.in-ulm.de> and subject line Re: Fwd: file(1) now with seccomp support enabled has caused the Debian Bug report #932580, regarding Fwd: file(1) now with seccomp support enabled to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@bugs.debian.org immediately.) -- 932580: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932580 Debian Bug Tracking System Contact owner@bugs.debian.org with problems
--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: Fwd: file(1) now with seccomp support enabled
- From: Paul Gevers <elbrus@debian.org>
- Date: Sat, 20 Jul 2019 22:27:32 +0200
- Message-id: <49d79410-6762-3ce7-d11d-f54a271a52a7@debian.org>
- In-reply-to: <1563549514@msgid.manchmal.in-ulm.de>
- References: <1563549514@msgid.manchmal.in-ulm.de>
Package: release-notes In order to not forget this. We should check what happened by the time we release bullseye. Paul -------- Forwarded Message -------- Subject: file(1) now with seccomp support enabled Resent-Date: Fri, 19 Jul 2019 15:25:41 +0000 (UTC) Resent-From: debian-devel@lists.debian.org Date: Fri, 19 Jul 2019 17:18:52 +0200 From: Christoph Biedl <debian-devel@lists.debian.org> To: debian-devel@lists.debian.org tl;dr: The file program in unstable is now built with seccomp support enabled, expect breakage in some rather uncommon use cases. Hello, Upstream of the file package added seccomp support a while ago, and probably everyone with even a small concern about security will agree the file program, often being used on dubious or even doubtless malicious input, should use seccomp to make the attack surface smaller. However I refrained from enabling this feature back then just weeks before the buster freeze, in restrospect: indeed the right decision. Now this early moment in the bullseye development cycle is a good time, so there's version 1:5.37-2, accepted in unstable a few moments ago. This however comes with a price: Some features are no longer available. For example, inspecting the content of compressed files (disabled by default, command-line parameters -z and -Z) is now supported for a few compressions only: gzip (and friends, see libz), bzip2, lzma, xz. Decompressing other formats requires invocation of external programs which will lead to a program abort (SIGSYS). Also, when running in LD_PRELOAD environments, that extra library may use blacklisted syscalls. One example is fakeroot which caused breakage in debhelper (#931985, already fixed). In both cases you should see a log message in the kernel log then. There is a workaround for such situations which is disabling seccomp, command line parameter --no-sandbox. But I have no idea about the impact this will cause. Checking all packages that (install-)depend on file for usage of these parameters turned out to be a fairly though job. Probably I've killed codesearch.d.n a few times, the term "file" is just very generic :) Some 53 binary packages have a dependency on the file package, two of them (cloud-utils, cracklib2) are very likely affected and will receive an extra bug report. Overall, I'm just asking to keep an eye on possible breakage, also check the kernel log. If you encounter one and can imagine a better solution than simply disabling seccomp in that case, let me know via the BTS. Finally, a clarification: Applications that link libmagic instead of calling the file executable are not affected by any of this. But the respective program authors might consider enabling seccomp on their own, for the above reason. Cheers, ChristophAttachment: signature.asc
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---
- To: Paul Gevers <elbrus@debian.org>
- Cc: 932580-done@bugs.debian.org
- Subject: Re: Fwd: file(1) now with seccomp support enabled
- From: Christoph Biedl <debian.axhn@manchmal.in-ulm.de>
- Date: Wed, 17 Mar 2021 22:10:58 +0100
- Message-id: <1616015372@msgid.manchmal.in-ulm.de>
- In-reply-to: <[🔎] 121a1ecd-7bdd-79e4-97e4-8c84db3602a2@debian.org>
- References: <1563549514@msgid.manchmal.in-ulm.de> <49d79410-6762-3ce7-d11d-f54a271a52a7@debian.org> <1563661427@msgid.manchmal.in-ulm.de> <1563661427@msgid.manchmal.in-ulm.de> <[🔎] 121a1ecd-7bdd-79e4-97e4-8c84db3602a2@debian.org>
Paul Gevers wrote... > Ping. Should we indeed add something to the release notes? Not needed. The seccomp support turned out to be not feasible, so I reverted it in 1:5.37-5 (July 2019). ChristophAttachment: signature.asc
Description: PGP signature
--- End Message ---