RATS Server Internals
The rats_server is a fairly simple program. It basically consists of
some daemon code, network read and write code, encryption code, pdb access
code, kerberos access code, and some command parser code. It's general
behavior is as follows:
-
Startup
-
Load the ratsconf file. If it fails log and exit.
-
Establish a listen socket. If it fails, log and exit.
-
On connection accept and fork a child.
-
Parent closes conversation socket, child closes listen socket.
-
Child verifies connection is from a valid client host by checking the ACL.
If no, log and exit.
-
Child accepts content over socket and decrypts it.
-
Child parses the command number. If decryption failed, or the api call
is outside of the client->server range, it fails, logs and exits.
-
If the api call is inside the valid range but unsupported, it fails, logs,
and exits.
-
If the call is valid, it passes the arguments onto either the kerberos
handling code or the pdb handling code. Each code finishes parsing the
input, does something, and returns a value to the client.
-
The child then continues listening for another command.
There are some basic design decisions that were made regarding the server.
First, network conversations are done in a manner where a 4 byte long integer
is sent over stating the length of the content to follow, then that amount
of content is read. If a read is not completed in 60 seconds, the server
will log a client time out and exit. There is however a hard upper limit
of 800 bytes set. This is to protect against buffer overflow attacks, and
was chosen because 800 bytes was sufficient to send a command plus all
the data elements required by us to do account creation all at once. No
call currently uses anywhere near 800 bytes. All data value lengths are
coded to be a maximum length that matches the length specified in the pdb.
For example, username has a maximum length of 100 characters, and email
513 characters. This is done for three reasons. First, anything longer
is going to fail against the pdb anyway because the longer strings will
never match the shorter content. Second, commands of arbitrary unlimited
length are a pain when allocating memory, and make it hard to tell the
difference between parsing a large command, a bad command, and the parser
just running off the end of allocated memory on a corrupted buffer or bad
data. Third, given the above two issues, failing before trying to massage
the data into something useful and letting oracle fail is faster and less
load on the pdb and the server running the machine. Any hard limits on
length, time, etc. are #deifned in rats_def.h. Currently the entire process
of the server is geared towards atomic actions. One request gets one response.
Making a command give multiple responses to a single request is trivial
(if you know how to use scroll cursors in ProC), but making the command
parser handle commands that need to span a single 800 byte call will require
some work. The server is by design fairly simple and compact. The above
bullet list and the API documentation should be enough to get you into
the code and help clarify the comments. That should then be enough information
to get a programmer started on maintenance and/or updates.