diff options
author | Omar Polo <op@omarpolo.com> | 2021-02-23 13:22:29 +0000 |
---|---|---|
committer | Omar Polo <op@omarpolo.com> | 2021-02-23 13:22:29 +0000 |
commit | 290b5baa97c9c4d05cff00882444eb6926b975fc (patch) | |
tree | b5eaf343fcc591bb68dcefb2cc3abb8aac922aa9 /README.md | |
parent | 9899a837afd7e0e35478ee9c7e5a0910205318cd (diff) |
updated readme
Diffstat (limited to 'README.md')
-rw-r--r-- | README.md | 42 |
1 files changed, 15 insertions, 27 deletions
@@ -12,12 +12,13 @@ featureful server. - reconfiguration: reload the running configuration without interruption - sandboxed by default on OpenBSD, Linux and FreeBSD + - automatic redirect/error pages (see `block return`) - IRI support (RFC3987) - punycode support - dual stack (IPv4 and IPv6) - automatic certificate generation for config-less mode - CGI scripts - - (very) low memory footprint + - low memory footprint - event-based asynchronous I/O model - small codebase, easily hackable - virtual hosts @@ -50,8 +51,8 @@ doesn't do that (yet). gmid has a rich configuration file, heavily inspired by OpenBSD' httpd. While you should definitely check the manpage because it -documents every option in depth, here's an example of what gmid can -do. +documents every option in depth, here's a small example of how a +configuration file looks like. ```conf ipv6 on # enable ipv6 @@ -71,21 +72,6 @@ server "example.com" { # change the index file name index "README.gmi" } - - # redirect /cgi/man/... to man.example.com/... - location "/cgi/man*" { - strip 2 - block return 31 "gemini://man.example.com%p" - } -} - -server "man.example.com" { - cert "..." - key "..." - root "/var/gemini/man.example.com" - - # handle every request with the CGI script `man' - entrypoint "man" } ``` @@ -151,19 +137,21 @@ create files inside the `regress` directory and bind the 10965 port. ## Architecture/Security considerations -gmid is composed by two processes: a listener and an executor. The -listener process is the only one that needs internet access and is -sandboxed. When a CGI script needs to be executed, the executor -(outside of the sandbox) sets up a pipe and gives one end to the -listener, while the other is bound to the CGI script standard output. -This way, is still possible to execute CGI scripts without -restrictions even in the presence of a sandboxed network process. +gmid is composed by four processes: the parent process, the logger, +the listener and the executor. The parent process is the only one +that doesn't drop privileges, but all it does is to wait for a SIGHUP +to reload the configuration and spawn a new generation of children +process. The logger processes gather the logs and prints 'em to +stderr or syslog (for the time being.) The listener process is the +only one that needs internet access and is sandboxed by default. The +executor process exists only to fork and execute CGI scripts. On OpenBSD, the listener runs with the `stdio recvfd rpath inet` pledges, while the executor has `stdio sendfd proc exec`; both have -unveiled only the served directories. +unveiled only the served directories. The logger process has pledge +`stdio`. -On FreeBSD, the executor process is sandboxed with `capsicum(4)`. +On FreeBSD, the listener process is sandboxed with `capsicum(4)`. On Linux, a `seccomp(2)` filter is installed in the listener to allow only certain syscalls, see [sandbox.c](sandbox.c) for more information |