From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073) Date: Wed, 26 Jan 2022 05:23:40 +0200 Message-ID: <8335lbi3ib.fsf@gnu.org> References: <164286838577.8429.4021499312049157333@vcs2.savannah.gnu.org> <20220122161946.44098C0DA30@vcs2.savannah.gnu.org> <877daqq9kp.fsf@yahoo.com> <83v8y9jnvt.fsf@gnu.org> <874k5tp8c2.fsf@yahoo.com> <83pmohjloh.fsf@gnu.org> <87sftd5hcv.fsf@gnus.org> <83ilu9ji0m.fsf@gnu.org> <87h79thyi0.fsf@gmail.com> <83bl01jbks.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24578"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, phst@google.com, rpluim@gmail.com, larsi@gnus.org, emacs-devel@gnu.org To: Philipp Stephani Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jan 26 04:24:28 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nCYv5-0006Af-Ov for ged-emacs-devel@m.gmane-mx.org; Wed, 26 Jan 2022 04:24:28 +0100 Original-Received: from localhost ([::1]:43470 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nCYv4-00041W-7Q for ged-emacs-devel@m.gmane-mx.org; Tue, 25 Jan 2022 22:24:26 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:34962) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nCYuT-0002gq-NB for emacs-devel@gnu.org; Tue, 25 Jan 2022 22:23:49 -0500 Original-Received: from [2001:470:142:3::e] (port=51998 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nCYuT-0008NV-Cc; Tue, 25 Jan 2022 22:23:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=mwaLJlTfAFD1hpZnHXN/a0+gpr5JoBRg6QkX9fSqrhM=; b=NwB+qClVR5qg iJ2Ggf9itI7V+oNo5gJ7zR4CUNpRQZnmEJUxAOJOfOwgz+i12parGZ9UvaBCEWneG57tAEU7wtLU9 cfs0G6CCiibJ73frBIP7SZdkhepLu86hnF8uimGmVP0quk0tMPr3vXlFUdSpgw3SXpXZZa3d2vWcY XAMV3D/40g0fQ3lRdrQGlnQVabKphMj7t16q+LQNlVNpXO4S7mgPw4q2VsI5mpAbUr0kEGEoY7xI7 CZeC+f3Ws5EAo8nU8lzCfNdMDdhvwB13OS/a+e1i7blZh0UWY1eGgzZsheCJQFx8Z6lqxsebdYLGL WY80ZxCsNLj120N6C57qMg==; Original-Received: from [87.69.77.57] (port=4150 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nCYuS-0007B8-U4; Tue, 25 Jan 2022 22:23:49 -0500 In-Reply-To: (message from Philipp Stephani on Tue, 25 Jan 2022 21:12:17 +0100) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:285409 Archived-At: > From: Philipp Stephani > Date: Tue, 25 Jan 2022 21:12:17 +0100 > Cc: Robert Pluim , > Lars Ingebrigtsen , > Po Lu , > Philipp Stephani , > emacs-devel@gnu.org > > > > > Am 24.01.2022 um 18:19 schrieb Eli Zaretskii : > > > >> From: Robert Pluim > >> Cc: Lars Ingebrigtsen , luangruo@yahoo.com, > >> phst@google.com, p.stephani2@gmail.com, emacs-devel@gnu.org > >> Date: Mon, 24 Jan 2022 17:47:19 +0100 > >> > >> Eli> It is very worrisome that a change in glibc can break Emacs like that. > >> Eli> I wonder what it means for the maintainability of Emacs in the long > >> Eli> run. I have a bad feeling about this. > >> > >> We can always default the seccomp support to off. > > > > If it's so fragile, perhaps we should. > > The seccomp support isn't fragile at all. It only relies on the Linux kernel and a small number of syscalls that haven't changed for a long time. > What is "fragile" here (though I think this wording is incorrect) is the generation of the default filter that we ship for convenience reasons. That one should be adapted (maybe a few times per year, so not very frequently) to newer libc versions. There's no other way since unknown syscalls in the filter can't be allowed for security reasons. IOW, this is unworkable in principle. Exactly my point.