Re: Hook for `_exit'

[Rich Felker <dalias@libc.org>]

On Fri, Aug 05, 2022 at 10:22:11AM +0200, Florian Weimer via Libc-alpha wrote:
> * Po Lu via Libc-alpha:
> 
> > I'd like to ask for a hook run before _exit kills the current thread.
> > The reason for requesting such a hook is that badly behaved libraries
> > such as GTK call _exit when the display connection is lost, without
> > leaving programs a chance to perform cleanup, such as saving files that
> > the user was working on.
> >
> > AFAIR, the GTK developers have already mentioned that they are unwilling
> > to add such a hook on their end (especially to GTK 3, which is no longer
> > receiving new features), and the chance of updated GTK versions getting
> > to users is exceedingly slim.
> >
> > A real life example of this problem would be:
> >
> >   https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-08/msg00433.html
> >
> > Where a user experienced a display disconnect, and as a result lost all
> > of his work with no clear indication of what happened.
> 
> I think even if we add the hook in glibc, GTK will find a way to
> terminate the process immediately by other means.  We already have exit,
> yet GTK deliberately chose not to use it.  So it doesn't look like
> something that can be solved with an in-process hook.

Exactly. This is just inviting an arms race. Next GTK does
syscall(__NR_exit_group, 1) and then glibc has to make syscall() check
for __NR_exit_group and call the application callback. Then GTK
inlines asm, and glibc needs to install a seccomp handler to block it.
Next...

And that's not even to mention the flip side problem this invites: bad
library code installing hooks for _exit that interfere with the
application's usage of it and make it unsafe, by doing things from the
callback that aren't safe in the context _exit is called from -- _exit
is required to be async-signal safe and can be called from all sorts
of nasty contexts, even vfork child(!!), where it's not safe for
random callback code to run.

> If you need to use a library with such an approach to error handling,
> but you want to recover from errors, you need to use fork and confine
> its use to a subprocess, and employ some IPC mechanism to maintain
> relevant state in a more persistent process (or keep a redo log in the
> file system).

Exactly. If you're going to run badly-behaved library code, you either
need to patch the bad behavior out of the library, or run the library
in an isolated execution context where it can't do any harm. The
latter is really the right approach here. Work out a protocol for
communication between a UI child process and the actual core program
and sandbox the former.