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:13:38 +0100
> Cc: rms@gnu.org,
>  Po Lu <luangruo@yahoo.com>,
>  Philipp Stephani <phst@google.com>,
>  emacs-devel@gnu.org
> 
> 
> 
> > Am 25.01.2022 um 13:08 schrieb Eli Zaretskii <eliz@gnu.org>:
> > 
> >> From: Richard Stallman <rms@gnu.org>
> >> Date: Mon, 24 Jan 2022 23:16:03 -0500
> >> Cc: luangruo@yahoo.com, phst@google.com, emacs-devel@gnu.org
> >> 
> >>> That can happen any day, if glibc folks make some change we didn't
> >>> know about.  We cannot chase glibc development forever, we will never
> >>> succeed catching up with them, certainly not in the long run.
> >> 
> >> It's true that problems like this can happen any day.  Not just with
> >> Glibc but with lots of libraries that Emacs uses.  But that has been
> >> the case for many years.  Are things getting worse in some way?
> > 
> > If frequent changes to glibc cause Emacs to crash, that is bad.
> 
> These "crashes" are the whole point and purpose of seccomp filters.  If an 
> Emacs process is sandboxed using a syscall filter, any unknown syscall has to 
> exit the process ("crash"), otherwise the sandbox would be insecure.

The important point is that it makes Emacs unusable in this mode.
Perhaps security-wise this is what you want, but I very much doubt
that users will be pleased.