* Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073) [not found] ` <20220122161946.44098C0DA30@vcs2.savannah.gnu.org> @ 2022-01-24 0:08 ` Po Lu 2022-01-24 10:44 ` Philipp Stephani 0 siblings, 1 reply; 18+ messages in thread From: Po Lu @ 2022-01-24 0:08 UTC (permalink / raw) To: emacs-devel; +Cc: Philipp Stephani Philipp Stephani <p.stephani2@gmail.com> writes: > branch: emacs-28 > commit 6d3608be88e1b30d2d10ee81f14dd485275c20ff > Author: Philipp Stephani <phst@google.com> > Commit: Philipp Stephani <phst@google.com> > > Seccomp: improve support for newer versions of glibc (Bug#51073) > > * lib-src/seccomp-filter.c (main): Allow 'pread64' and 'faccessat2' > system calls. Newer versions of glibc use these system call (starting > with commits 95c1056962a3f2297c94ce47f0eaf0c5b6563231 and > 3d3ab573a5f3071992cbc4f57d50d1d29d55bde2, respectively). This seems to break the build for many people running older glibc versions. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073) 2022-01-24 0:08 ` emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073) Po Lu @ 2022-01-24 10:44 ` Philipp Stephani 2022-01-24 12:53 ` Eli Zaretskii 2022-01-25 4:16 ` Richard Stallman 0 siblings, 2 replies; 18+ messages in thread From: Philipp Stephani @ 2022-01-24 10:44 UTC (permalink / raw) To: Po Lu; +Cc: Philipp Stephani, Emacs developers Am Mo., 24. Jan. 2022 um 01:09 Uhr schrieb Po Lu <luangruo@yahoo.com>: > > Philipp Stephani <p.stephani2@gmail.com> writes: > > > branch: emacs-28 > > commit 6d3608be88e1b30d2d10ee81f14dd485275c20ff > > Author: Philipp Stephani <phst@google.com> > > Commit: Philipp Stephani <phst@google.com> > > > > Seccomp: improve support for newer versions of glibc (Bug#51073) > > > > * lib-src/seccomp-filter.c (main): Allow 'pread64' and 'faccessat2' > > system calls. Newer versions of glibc use these system call (starting > > with commits 95c1056962a3f2297c94ce47f0eaf0c5b6563231 and > > 3d3ab573a5f3071992cbc4f57d50d1d29d55bde2, respectively). > > This seems to break the build for many people running older glibc > versions. I forgot to bump the minimum libseccomp version. I've done that now (commit c34d06e3d75bfbea2605e3ae292850175ce5c235). ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073) 2022-01-24 10:44 ` Philipp Stephani @ 2022-01-24 12:53 ` Eli Zaretskii 2022-01-24 13:33 ` Po Lu 2022-01-25 4:16 ` Richard Stallman 1 sibling, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2022-01-24 12:53 UTC (permalink / raw) To: Philipp Stephani; +Cc: luangruo, phst, emacs-devel > From: Philipp Stephani <p.stephani2@gmail.com> > Date: Mon, 24 Jan 2022 11:44:34 +0100 > Cc: Philipp Stephani <phst@google.com>, Emacs developers <emacs-devel@gnu.org> > > Am Mo., 24. Jan. 2022 um 01:09 Uhr schrieb Po Lu <luangruo@yahoo.com>: > > > > Philipp Stephani <p.stephani2@gmail.com> writes: > > > > > branch: emacs-28 > > > commit 6d3608be88e1b30d2d10ee81f14dd485275c20ff > > > Author: Philipp Stephani <phst@google.com> > > > Commit: Philipp Stephani <phst@google.com> > > > > > > Seccomp: improve support for newer versions of glibc (Bug#51073) > > > > > > * lib-src/seccomp-filter.c (main): Allow 'pread64' and 'faccessat2' > > > system calls. Newer versions of glibc use these system call (starting > > > with commits 95c1056962a3f2297c94ce47f0eaf0c5b6563231 and > > > 3d3ab573a5f3071992cbc4f57d50d1d29d55bde2, respectively). > > > > This seems to break the build for many people running older glibc > > versions. > > I forgot to bump the minimum libseccomp version. I've done that now > (commit c34d06e3d75bfbea2605e3ae292850175ce5c235). Why do we need this and the previous change on the release branch? There were zero complaints until now about seccomp for Emacs 28. Can we revert the original change in the first place? ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073) 2022-01-24 12:53 ` Eli Zaretskii @ 2022-01-24 13:33 ` Po Lu 2022-01-24 13:41 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Po Lu @ 2022-01-24 13:33 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Philipp Stephani, phst, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > Why do we need this and the previous change on the release branch? > There were zero complaints until now about seccomp for Emacs 28. > Can we revert the original change in the first place? It apparently leads to crashes when Emacs is run under seccomp with a recent glibc version. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073) 2022-01-24 13:33 ` Po Lu @ 2022-01-24 13:41 ` Eli Zaretskii 2022-01-24 14:38 ` Lars Ingebrigtsen 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2022-01-24 13:41 UTC (permalink / raw) To: Po Lu; +Cc: phst, p.stephani2, emacs-devel > From: Po Lu <luangruo@yahoo.com> > Cc: Philipp Stephani <p.stephani2@gmail.com>, phst@google.com, > emacs-devel@gnu.org > Date: Mon, 24 Jan 2022 21:33:01 +0800 > > Eli Zaretskii <eliz@gnu.org> writes: > > > Why do we need this and the previous change on the release branch? > > There were zero complaints until now about seccomp for Emacs 28. > > > Can we revert the original change in the first place? > > It apparently leads to crashes when Emacs is run under seccomp with a > recent glibc version. 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073) 2022-01-24 13:41 ` Eli Zaretskii @ 2022-01-24 14:38 ` Lars Ingebrigtsen 2022-01-24 15:00 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Lars Ingebrigtsen @ 2022-01-24 14:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Po Lu, phst, p.stephani2, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> It apparently leads to crashes when Emacs is run under seccomp with a >> recent glibc version. > > 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. But this is a known glibc issue, and crashes aren't fun, so I think the seccomp change was warranted on the release branch. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073) 2022-01-24 14:38 ` Lars Ingebrigtsen @ 2022-01-24 15:00 ` Eli Zaretskii 2022-01-24 16:47 ` Robert Pluim 2022-01-25 20:09 ` Philipp Stephani 0 siblings, 2 replies; 18+ messages in thread From: Eli Zaretskii @ 2022-01-24 15:00 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: luangruo, phst, p.stephani2, emacs-devel > From: Lars Ingebrigtsen <larsi@gnus.org> > Date: Mon, 24 Jan 2022 15:38:24 +0100 > Cc: Po Lu <luangruo@yahoo.com>, phst@google.com, p.stephani2@gmail.com, > emacs-devel@gnu.org > > Eli Zaretskii <eliz@gnu.org> writes: > > >> It apparently leads to crashes when Emacs is run under seccomp with a > >> recent glibc version. > > > > 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. > > But this is a known glibc issue, and crashes aren't fun, so I think the > seccomp change was warranted on the release branch. It is very worrisome that a change in glibc can break Emacs like that. I wonder what it means for the maintainability of Emacs in the long run. I have a bad feeling about this. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073) 2022-01-24 15:00 ` Eli Zaretskii @ 2022-01-24 16:47 ` Robert Pluim 2022-01-24 17:19 ` Eli Zaretskii 2022-01-25 20:09 ` Philipp Stephani 1 sibling, 1 reply; 18+ messages in thread From: Robert Pluim @ 2022-01-24 16:47 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, phst, Lars Ingebrigtsen, p.stephani2, emacs-devel >>>>> On Mon, 24 Jan 2022 17:00:25 +0200, Eli Zaretskii <eliz@gnu.org> said: >> From: Lars Ingebrigtsen <larsi@gnus.org> >> Date: Mon, 24 Jan 2022 15:38:24 +0100 >> Cc: Po Lu <luangruo@yahoo.com>, phst@google.com, p.stephani2@gmail.com, >> emacs-devel@gnu.org >> >> Eli Zaretskii <eliz@gnu.org> writes: >> >> >> It apparently leads to crashes when Emacs is run under seccomp with a >> >> recent glibc version. >> > >> > 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. >> >> But this is a known glibc issue, and crashes aren't fun, so I think the >> seccomp change was warranted on the release branch. 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. Robert -- ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073) 2022-01-24 16:47 ` Robert Pluim @ 2022-01-24 17:19 ` Eli Zaretskii 2022-01-25 20:12 ` Philipp Stephani 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2022-01-24 17:19 UTC (permalink / raw) To: Robert Pluim; +Cc: luangruo, phst, larsi, p.stephani2, emacs-devel > 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073) 2022-01-24 17:19 ` Eli Zaretskii @ 2022-01-25 20:12 ` Philipp Stephani 2022-01-26 3:23 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Philipp Stephani @ 2022-01-25 20:12 UTC (permalink / raw) To: Eli Zaretskii Cc: Po Lu, Philipp Stephani, Robert Pluim, Lars Ingebrigtsen, emacs-devel > 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073) 2022-01-25 20:12 ` Philipp Stephani @ 2022-01-26 3:23 ` Eli Zaretskii 0 siblings, 0 replies; 18+ messages in thread From: Eli Zaretskii @ 2022-01-26 3:23 UTC (permalink / raw) To: Philipp Stephani; +Cc: luangruo, phst, rpluim, larsi, emacs-devel > 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073) 2022-01-24 15:00 ` Eli Zaretskii 2022-01-24 16:47 ` Robert Pluim @ 2022-01-25 20:09 ` Philipp Stephani 2022-01-25 21:40 ` Stefan Monnier 2022-01-26 3:22 ` Eli Zaretskii 1 sibling, 2 replies; 18+ messages in thread From: Philipp Stephani @ 2022-01-25 20:09 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Po Lu, Philipp Stephani, Lars Ingebrigtsen, emacs-devel > Am 24.01.2022 um 16:00 schrieb Eli Zaretskii <eliz@gnu.org>: > >> From: Lars Ingebrigtsen <larsi@gnus.org> >> Date: Mon, 24 Jan 2022 15:38:24 +0100 >> Cc: Po Lu <luangruo@yahoo.com>, phst@google.com, p.stephani2@gmail.com, >> emacs-devel@gnu.org >> >> Eli Zaretskii <eliz@gnu.org> writes: >> >>>> It apparently leads to crashes when Emacs is run under seccomp with a >>>> recent glibc version. >>> >>> 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. >> >> But this is a known glibc issue, and crashes aren't fun, so I think the >> seccomp change was warranted on the release branch. > > It is very worrisome that a change in glibc can break Emacs like that. > I wonder what it means for the maintainability of Emacs in the long > run. I have a bad feeling about this. Just to clarify this, nothing here has really broken Emacs. Emacs itself doesn't depend on libseccomp or the specific seccomp filter at all. It's just that newer versions of glibc will occasionally add new syscalls which will then need to get added to seccomp filters for sandboxing to continue working; the sandbox can only be secure if it fails-close (i.e. exits the process when encountering an unknown syscall). ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073) 2022-01-25 20:09 ` Philipp Stephani @ 2022-01-25 21:40 ` Stefan Monnier 2022-01-26 3:22 ` Eli Zaretskii 1 sibling, 0 replies; 18+ messages in thread From: Stefan Monnier @ 2022-01-25 21:40 UTC (permalink / raw) To: Philipp Stephani Cc: Eli Zaretskii, Po Lu, Philipp Stephani, Lars Ingebrigtsen, emacs-devel > Just to clarify this, nothing here has really broken Emacs. Emacs itself > doesn't depend on libseccomp or the specific seccomp filter at all. It's > just that newer versions of glibc will occasionally add new syscalls which > will then need to get added to seccomp filters for sandboxing to continue > working; the sandbox can only be secure if it fails-close (i.e. exits the > process when encountering an unknown syscall). Maybe you need to clarify what "makes Emacs crash" means, then. To clarify, my understanding so far based on your description (and my lack of understanding of how seccomp is currently used in Emacs) is that an Emacs built with support for seccomp would be 100% unusable without the recent adjustment, when run on a system using a new glibc. If that is not the case, then please clarify in which circumstances the problem shows up. If it is the case, then it means we may need a way for users to update the seccomp filter without recompiling&reinstalling Emacs, so they can keep using their Emacs-28.1 when glibc is changed again two years from now. Stefan ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073) 2022-01-25 20:09 ` Philipp Stephani 2022-01-25 21:40 ` Stefan Monnier @ 2022-01-26 3:22 ` Eli Zaretskii 1 sibling, 0 replies; 18+ messages in thread From: Eli Zaretskii @ 2022-01-26 3:22 UTC (permalink / raw) To: Philipp Stephani; +Cc: luangruo, phst, larsi, emacs-devel > From: Philipp Stephani <p.stephani2@gmail.com> > Date: Tue, 25 Jan 2022 21:09:24 +0100 > Cc: Lars Ingebrigtsen <larsi@gnus.org>, > Po Lu <luangruo@yahoo.com>, > Philipp Stephani <phst@google.com>, > emacs-devel@gnu.org > > > It is very worrisome that a change in glibc can break Emacs like that. > > I wonder what it means for the maintainability of Emacs in the long > > run. I have a bad feeling about this. > > Just to clarify this, nothing here has really broken Emacs. Emacs itself doesn't depend on libseccomp or the specific seccomp filter at all. It's just that newer versions of glibc will occasionally add new syscalls which will then need to get added to seccomp filters for sandboxing to continue working; the sandbox can only be secure if it fails-close (i.e. exits the process when encountering an unknown syscall). That is exactly my problem with these situations: sandboxed Emacs stops working too frequently for that to be a reliable option. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073) 2022-01-24 10:44 ` Philipp Stephani 2022-01-24 12:53 ` Eli Zaretskii @ 2022-01-25 4:16 ` Richard Stallman 2022-01-25 12:08 ` Eli Zaretskii 1 sibling, 1 reply; 18+ messages in thread From: Richard Stallman @ 2022-01-25 4:16 UTC (permalink / raw) To: Philipp Stephani; +Cc: luangruo, phst, emacs-devel [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > This seems to break the build for many people running older glibc > > versions. > I forgot to bump the minimum libseccomp version. I've done that now > (commit c34d06e3d75bfbea2605e3ae292850175ce5c235). Concretely, what will the effect of this be on people who build with an older Glibc version installed? > 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? -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073) 2022-01-25 4:16 ` Richard Stallman @ 2022-01-25 12:08 ` Eli Zaretskii 2022-01-25 20:13 ` Philipp Stephani 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2022-01-25 12:08 UTC (permalink / raw) To: rms; +Cc: luangruo, phst, p.stephani2, emacs-devel > 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. Emacs should not have such a critical dependency on changes in the library, and it shouldn't be that fragile. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073) 2022-01-25 12:08 ` Eli Zaretskii @ 2022-01-25 20:13 ` Philipp Stephani 2022-01-26 3:24 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Philipp Stephani @ 2022-01-25 20:13 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Po Lu, Philipp Stephani, rms, emacs-devel > 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073) 2022-01-25 20:13 ` Philipp Stephani @ 2022-01-26 3:24 ` Eli Zaretskii 0 siblings, 0 replies; 18+ messages in thread From: Eli Zaretskii @ 2022-01-26 3:24 UTC (permalink / raw) To: Philipp Stephani; +Cc: luangruo, phst, rms, emacs-devel > 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2022-01-26 3:24 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <164286838577.8429.4021499312049157333@vcs2.savannah.gnu.org> [not found] ` <20220122161946.44098C0DA30@vcs2.savannah.gnu.org> 2022-01-24 0:08 ` emacs-28 6d3608be88: Seccomp: improve support for newer versions of glibc (Bug#51073) Po Lu 2022-01-24 10:44 ` Philipp Stephani 2022-01-24 12:53 ` Eli Zaretskii 2022-01-24 13:33 ` Po Lu 2022-01-24 13:41 ` Eli Zaretskii 2022-01-24 14:38 ` Lars Ingebrigtsen 2022-01-24 15:00 ` Eli Zaretskii 2022-01-24 16:47 ` Robert Pluim 2022-01-24 17:19 ` Eli Zaretskii 2022-01-25 20:12 ` Philipp Stephani 2022-01-26 3:23 ` Eli Zaretskii 2022-01-25 20:09 ` Philipp Stephani 2022-01-25 21:40 ` Stefan Monnier 2022-01-26 3:22 ` Eli Zaretskii 2022-01-25 4:16 ` Richard Stallman 2022-01-25 12:08 ` Eli Zaretskii 2022-01-25 20:13 ` Philipp Stephani 2022-01-26 3:24 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).