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:22:51 +0200 Message-ID: <834k5ri3jo.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> <17E6AEF0-D704-44FB-8B2F-6DCDE67EE22F@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22387"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, phst@google.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:00 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 1nCYue-0005ee-5R for ged-emacs-devel@m.gmane-mx.org; Wed, 26 Jan 2022 04:24:00 +0100 Original-Received: from localhost ([::1]:41576 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nCYuc-0002mL-MQ for ged-emacs-devel@m.gmane-mx.org; Tue, 25 Jan 2022 22:23:58 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:34870) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nCYti-0001zM-0w for emacs-devel@gnu.org; Tue, 25 Jan 2022 22:23:02 -0500 Original-Received: from [2001:470:142:3::e] (port=51976 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 1nCYth-0008Kg-Fi; Tue, 25 Jan 2022 22:23:01 -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=TGPo0sJzeIKZfEXYFHKD07Lxzsme7amOdgCd0dRZ/ws=; b=VPmc7LLZOlJL cRIbOVEwZflCyTmRQ4t2qpKjFtxdguN5Z32kJu1jbxLY8AKNKn60IUVSn5LAwpxZWCypgV0gwR1Ib iJEM9kELsKOxEvTF6eXl3mMNAQTHIP+UaSTTdv9AI9E8CtkL8KGNXtSxW+wAU0cU9YdxZvVBR0SH9 QzcNex3YggffTP8ozSHvKaOAdTWQaOS7H+HQ7OfSUUlG660yg6NqnuWwD7+u9ziAm0PjIJ8K3bzE7 xTW4NVpgh9TMLy8/SXyla6uSTPkdJet2GA47liskZkP1WGC6q8hH53tZxoPniLJUXpUJPAuc76hb6 q4KPjkyFwFrbDKsewgSgEA==; Original-Received: from [87.69.77.57] (port=4098 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 1nCYtg-00077K-Vs; Tue, 25 Jan 2022 22:23:01 -0500 In-Reply-To: <17E6AEF0-D704-44FB-8B2F-6DCDE67EE22F@gmail.com> (message from Philipp Stephani on Tue, 25 Jan 2022 21:09:24 +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:285408 Archived-At: > From: Philipp Stephani > Date: Tue, 25 Jan 2022 21:09:24 +0100 > Cc: Lars Ingebrigtsen , > Po Lu , > Philipp Stephani , > emacs-devel@gnu.org > > > It is very worrisome that a change in glibc can break Emacs like that. > > I wonder what it means for the maintainability of Emacs in the long > > run. I have a bad feeling about this. > > Just to clarify this, nothing here has really broken Emacs. Emacs itself doesn't depend on libseccomp or the specific seccomp filter at all. It's just that newer versions of glibc will occasionally add new syscalls which will then need to get added to seccomp filters for sandboxing to continue working; the sandbox can only be secure if it fails-close (i.e. exits the process when encountering an unknown syscall). That is exactly my problem with these situations: sandboxed Emacs stops working too frequently for that to be a reliable option.