[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of
Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073)
Wed, 26 Jan 2022 05:24:41 +0200
> From: Philipp Stephani <email@example.com>
> Date: Tue, 25 Jan 2022 21:13:38 +0100
> Cc: firstname.lastname@example.org,
> Po Lu <email@example.com>,
> Philipp Stephani <firstname.lastname@example.org>,
> > Am 25.01.2022 um 13:08 schrieb Eli Zaretskii <email@example.com>:
> >> From: Richard Stallman <firstname.lastname@example.org>
> >> Date: Mon, 24 Jan 2022 23:16:03 -0500
> >> Cc: email@example.com, firstname.lastname@example.org, email@example.com
> >>> 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