new I/O handling on top of bufferevents This is a big change in how gmid handles I/O. Initially we used a hand-written loop over poll(2), that then was evolved into something powered by libevent basic API. This meant that there were a lot of small "asynchronous" function that did one step, eventually scheduling the re-execution, that called each others in a chain. The new implementation revolves completely around libevent' bufferevents. It's more clear, as everything is implemented around the client_read and client_write functions. There is still space for improvements, like adding timeouts for one, but it's solid enough to be committed as is and then further improved.

[cgi] switch from pipe(2) to socketpair(2) We can't use normal pipe(2)s with libevent in some cases. Switch to socketpair(2), which doesn't have the same problem. This has the drawback that it doesn't prevent the CGI script from reading stdout, for instance. (sockets are two-way, pipes only one-way)

log more details for FastCGI errors add the reported request id if there's a mismatch and both the gai error and the errno value if getnameinfo fails.

simplify error check


enforce PR_SET_NO_NEW_PRIVS in the logger process otherwise landlock will refuse to enable itself and the logger process dies.

forgot include

[seccomp] allow ioctl(FIONREAD) it's needed by bufferevent_read

sync changelog

fastcgi completely asynchronous This changes the fastcgi implementation from a blocking I/O to an async implementation on top of libevent' bufferevents. Should improve the responsiveness of gmid especially when using remote fastcgi applications.

initialize mbufhead

refactor landlock refactor the landlock-related code into something more manageable. The only real difference is that before the logger process would try to landlock itself to "/" without perms, something that landlock doesn't support (now it enables landlock and then restrict itself, which is the correct move.)

mention the thanks to cage for the bugfix Since I was in a hurry, I forgot to mention it in the tag message :/

sync release

fix possible out-of-bound access While computing the parent directory it an out-of-bound access can occur, which usually means the server process dies. In particular, it can be triggered by making a request for a non-existent file in the root of a virtual host if the path matches the `cgi` pattern. Thanks cage for helping in debugging!