Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073)

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Tue, 25 Jan 2022 21:12:17 +0100
> Cc: Robert Pluim <rpluim@gmail.com>,
>  Lars Ingebrigtsen <larsi@gnus.org>,
>  Po Lu <luangruo@yahoo.com>,
>  Philipp Stephani <phst@google.com>,
>  emacs-devel@gnu.org
> 
> 
> 
> > Am 24.01.2022 um 18:19 schrieb Eli Zaretskii <eliz@gnu.org>:
> > 
> >> From: Robert Pluim <rpluim@gmail.com>
> >> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  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.