It's been there for a long time, and it's frankly annoying to pretend to use parameters. Most of the time, they're there to satisfy an interface and nothings more.

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

it's needed by bufferevent_read

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.)

Disallow everything landlock can handle. The logger process doesn't need any fs access (on OpenBSD it runs with pledge("stdio recvfd")).

Trying to implement some landlock policies (rules?) where possible. The server process is, of course, the most dangerous process so start with that. The following should be equivalent to the unveil(2) call on OpenBSD: allows only to read files and directories inside the vhost roots. I'm assuming seccomp is enabled so I'm not trying to disallow actions such as LANDLOCK_ACCESS_FS_EXECUTE or LANDLOCK_ACCESS_FS_REMOVE_FILE which require syscalls that are already disallowed. I'm only trying to limit the damage that the currently allowed system calls can do. e.g. since write(2) is allowed, gmid could modify *any* file it has access to; this is now forbidden by landlock. There are still too many #ifdefs for my tastes, but it's still better than the seccomp code.

Since there was 0 reports in a month can I assume it's not actually used anywhere?

used by glibc on aarch64. Found and tested by pine, thanks!