[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of
From: |
Eli Zaretskii |
Subject: |
Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073) |
Date: |
Wed, 26 Jan 2022 05:24:41 +0200 |
> 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.
Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073), Richard Stallman, 2022/01/24