[Sudoscript-devel] 2.0 Architecture

[Howard O. <hb...@eg...>]

I now have Perl code to implement a 2.0 architecture for sudoscript
that enables multiuser operation while tagging sessions with the
username and process ID. I have retained the separate sudoshell and
sudoscriptd split. I looked at merging thee two based on C code posted
by Adam Morris, but I couldn't get it working in Perl. (Neither the
child nor the parent processes could hold on to stdin/stdout in my tests.)
I also judged that it would be good to have just one log file, so
as to simplify the management of the probably large quantity of data, and
that requires a daemon. So attached is my diagram of the new architecture.

Here's how it works. Sudoscriptd starts up and opens a front-end FIFO.
It also forks a backend daemon to manage the single log file. The backend
daemon creates a FIFO of its own and lurks waiting for data. When sudoshell
runs, it sends a 'HELO' string to the frontend daemon over the frontend
FIFO, then does a Posix::pause with a SIGHUP handler in place. (This
idea is due to Adam Morris.) The frontend daemon forks a logger, which 
creates
a session FIFO, whose name is derived from the username and PID given by 
sudoshell.
It then sends a HUP signal to sudoshell and opens the session FIFO for read.
Sudoshell wakes up and invokes script(1) onto the session FIFO, whose name 
it derives
from its own username and PID. The logger tags all data it receives with the
session ID, and logs it all to the backend FIFO. The backend sudoscriptd 
merges the
data onto a log file after date-stamping it. It also checks the log file 
size
every 30 seconds, rotating and compressing it as needed.

All the daemons now use sys to report their progress. All have signal 
handlers
to gracefully shut down. The frontend sudoscriptd tracks all extant 
processes.
When sudoshell exits, it tells the frontend daemon so, which shuts down the 
associated
logger.

This architecture is considerably more complicated than the 1.0 code. I 
think there
are definite benefits for the added complexity. Mainly it allows tracking 
of individual
sessions, while retaining the benefits of a single log file. Nevertheless, 
I'm
going to test it much more extensively on the architectures I have
access to. After that, I'll do a beta release and gather feedback from the
adventurous, before doing a final release.

I'll branch the repository sometime today and commit the new code. I'll 
announce its
availability here when I'm done.

--
Howard Owen                      "Even if you are on the right
EGBOK Consultants                 track, you'll get run over if you
hb...@eg...    +1-650-339-5733  just sit there." - Will Rogers