From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073) Date: Tue, 25 Jan 2022 16:40:34 -0500 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33937"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Eli Zaretskii , Po Lu , Philipp Stephani , Lars Ingebrigtsen , emacs-devel@gnu.org To: Philipp Stephani Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 25 22:44:06 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 1nCTbh-0008cy-Od for ged-emacs-devel@m.gmane-mx.org; Tue, 25 Jan 2022 22:44:05 +0100 Original-Received: from localhost ([::1]:47874 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nCTbf-00045n-DS for ged-emacs-devel@m.gmane-mx.org; Tue, 25 Jan 2022 16:44:03 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:58978) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nCTYY-0002lE-35 for emacs-devel@gnu.org; Tue, 25 Jan 2022 16:40:50 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:22852) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nCTYN-0007qC-VG; Tue, 25 Jan 2022 16:40:42 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 253CA805EF; Tue, 25 Jan 2022 16:40:37 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id B758580297; Tue, 25 Jan 2022 16:40:35 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1643146835; bh=pmNM87VpOyJbtajBpd+KLpJcWLUD/8cJEITBRNBuZqs=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=W9gNW2ZMBWsVcuatu20SM/fGLDR4rjB519GgFVJceEpS9lGsVBGVoGf+3XNkMc7sv /Zg/CpMBwX0wFY1tlBrGjBR5SaCFirXdEJLm1KGptVdssbf0iOmkEpQr4k6txGXuas 1S0cytzqaIMkzJzDeWMOBbrk8oNrGEKkG+/cfk9JfhalphhcXsjAkhNTnDgWP37Xou qlCsBUOjrIe5QaQY/WkATnsg/Ft9/2btxtNqovQ1ax2s06xb+xj2ql+q4olJo6hqpO G2KTCqFWrJRgeLaU7qjhBqch1rcgXW9KmmQSd9kSLEIFHm7k1FJ8nApIApJDib5vg1 9deCE/zpP4usQ== Original-Received: from pastel (unknown [216.154.30.173]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 74412120489; Tue, 25 Jan 2022 16:40:35 -0500 (EST) In-Reply-To: <17E6AEF0-D704-44FB-8B2F-6DCDE67EE22F@gmail.com> (Philipp Stephani's message of "Tue, 25 Jan 2022 21:09:24 +0100") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:285400 Archived-At: > 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). Maybe you need to clarify what "makes Emacs crash" means, then. To clarify, my understanding so far based on your description (and my lack of understanding of how seccomp is currently used in Emacs) is that an Emacs built with support for seccomp would be 100% unusable without the recent adjustment, when run on a system using a new glibc. If that is not the case, then please clarify in which circumstances the problem shows up. If it is the case, then it means we may need a way for users to update the seccomp filter without recompiling&reinstalling Emacs, so they can keep using their Emacs-28.1 when glibc is changed again two years from now. Stefan