The *POST /auth/login* operation authenticates a user given a username
and password. The actual authentication is preformed by the daemon,
since it is privileged and will be able to read `/etc/shadow` via the
`pam_unix.so` module.
Upon successful login, a signed cookie containing the username is set
for the client. I'm not sure if any other information will need to be
stored in the cookie yet. The cookie contains a JSON document that we
can extend if necessary.
Starting work on the JSON-RPC client in the web server.
The `Context` structure, which is stored in Rocket's managed state and
available to route functions through the `State` request guard, provides
a method to get an RPC client. Each request that needs to communicate
with the daemon will have its own RPC connection. This ensures that a
valid connection is always available, even if the daemon has restarted
between web requests. I had considered storing the connection in the
context, testing it each time it was needed, and reconnecting if the
connection was broken. This proved very difficult, since the context is
passed to request handlers as an immutable reference. Mutating its
state would require locking, and I could not make that work easily.
Besides, the overhead of "pinging" the server for every request is
probably greater than just reconnecting every time, so it would have
been a waste.
The *GET /status* operation returns a document that indicates the status
of the daemon and the web server.
Beginning the implementation of the JSON-RPC server in the privileged
daemon. We're using *jsonrpc-core* for the JSON-RPC implementation,
which includes serialization, connection handling, and method dispatch.
The first RPC method is a simple status query, which returns the daemon
version and the number of seconds the daemon process has been running.
The backend will be split into two processes:
* The privileged daemon
* The unprivileged web server
These processes will communicate using JSON-RPC over a UNIX socket. The
web server is unprivileged to mitigate the risk of vulnerabilities being
exploited to gain control of the system. The privileged daemon will
handle all actual firewall management. Additionally, the backend also
acts as a command-line interface for communicating with the daemon.
The application's main entry point determines which process to launch
based on the name of the executable. This can be controlled, e.g. by
creating symbolic links pointing to the binary, or using the `@` prefix
in the `ExecStart` setting in a systemd unit.
This first commit introduces the Rocket framework for the web process.
Unfortunately, Rocket is rather inflexible in how it is started. It
expects to have complete control of the `main` function, and does not
provide any mechanism for passing data to its initialization routines.
Thus, in order to configure it using command-line arguments, arguments
have to be parsed inside Rocket's main function; they cannot be parsed
ahead of time and passed in.
Dustin