[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:23:40 +0200 |
> 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.
- Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073), Po Lu, 2022/01/23
- Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073), Philipp Stephani, 2022/01/24
- Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073), Eli Zaretskii, 2022/01/24
- Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073), Po Lu, 2022/01/24
- Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073), Eli Zaretskii, 2022/01/24
- Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073), Lars Ingebrigtsen, 2022/01/24
- Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073), Eli Zaretskii, 2022/01/24
- Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073), Robert Pluim, 2022/01/24
- Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073), Eli Zaretskii, 2022/01/24
- Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073), Philipp Stephani, 2022/01/25
- Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073),
Eli Zaretskii <=
- Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073), Philipp Stephani, 2022/01/25
- Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073), Stefan Monnier, 2022/01/25
- Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073), Eli Zaretskii, 2022/01/25
Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073), Richard Stallman, 2022/01/24