libevent2 has this concept of "freezeness" of a buffer. It's a way to
avoid accidentally write/remove data from the wrong "edge" of the
buffer. The client_tls_{read,write} functions need to add/drain data
from the opposite edge, hence the need for the unfreeze call.
This is the minimum change in order to work on libevent2 too. Another
way would be to define evbuffer_{un,}freeze as NOP on libevent 1, but
it's ugly IMHO.
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.
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)
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.
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.)
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!
There's no difference, but bzero(3) says
STANDARDS
The bzero() function conforms to the X/Open System Interfaces option of
the IEEE Std 1003.1-2004 (“POSIX.1”) specification. It was removed from
the standard in IEEE Std 1003.1-2008 (“POSIX.1”), which recommends using
memset(3) instead.
so here we are.
the whole struct client is already memset'd to 0 in do_accept.
handle_handshake doesn't touch the request or iri buffer in the code
path that leads to handle_open_conn. (It does so in the error router
alone.)
Missing SNI (i.e. servname == NULL) is already handled correctly.
puny_decode refuses to work on NULL servname, c->domain is still the
empty string and everything flows as expected towards the error at the
end. However, it's better to bail out early and make more explicit
how the case of missing SNI is handled.
Changed gmid.service to not to fork the server and forced to run under
user "gmid". gmid now waits for the network stack beeing available
before starting. Also "gmid" is now the syslog id.
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.
First move towards landlock support (#3). The shim is needed until
libc provides the proper wrappers for the landlock APIs; I hope it
doesn't take too long, but landlock was merged back in May and are
still missing.
Due to capsicum(4), opening the log on-demand via syslog(3) fails.
openlog(LOG_NDELAY) forces the log to be opened immediately, before we
enter capsicum.
This doesn't affect OpenBSD (where pledge(2) doesn't stop syslog) nor
linux (where the log process is not sandboxed.)
Reported by Karl Jeacle, thank you!
Omar Polo
Martin
Anna “CyberTailor”