to connect to unix-domain sockets the `unix' pledge is needed and also
unveil "w". gmid can't mutate files because it doesn't pledge `wpath'
nor `cpath'.
Both Linux and OpenBSD have LOGIN_NAME_MAX available when including
limits.h, FreeBSD, Darwin and possibly others don't.
FreeBSD (and maybe Darwin) have MAXLOGNAME, so try to use that if
available. Otherwise use _POSIX_LOGIN_NAME_MAX, but only has a fallback
since it has a lower value (9 at the time of writing).
If everything fails, use 32 which is what OpenBSD use by default;
OpenSMTPd also defaults to it.
(compat copied from kamid.)
The code in fcgi_req to send the custom params set in the config file was
placed inside the conditional for `tls_peer_cert_provided`, so the custom
parameters would not be sent if a client certificate is not provided.
The FreeBSD and Linux' sandbox can't deal with `fastcgi' and `proxy'
configuration rules: new sockets needs to be opened and it's either
impossible (the former) or a huge pain in the arse (the latter).
The sandbox is still always used in case only static files are served.
I really want to get rid of the `executor' process hack for CGI scripts
and its escalation to allow fastcgi and proxying to work on non-OpenBSD.
This drops the CGI support and the `executor' process entirely and is
the first step towards gmid 2.0. It also allows to have more secure
defaults.
On non-OpenBSD systems this means that the sandbox will be deactivated
as soon as fastcgi or proxying are used: you can't open sockets under
FreeBSD' capsicum(4) and I don't want to go thru the pain of making it
work under linux' seccomp/landlock. Patches are always welcome however.
For folks using CGI scripts (hey, I'm one of you!) not all hope is lost:
fcgiwrap or OpenBSD' slowcgi(8) are ways to run CGI scripts as they were
FastCGI applications.
fixes for the documentation and to the non-OpenBSD sandboxes will
follow.