sudoscriptd - logging daemons for sudoshell(1)


  sudoscriptd [-d|--datefmt long|short|sortable]


This manpage documents version 2.1.2 of sudoscriptd


sudoscriptd is a daemon for logging output from sudoshell(8). Used with that script, it provides an audit trail for shells run under sudo.


When sudoscriptd starts, it creates a named pipe (FIFO) in a spool area. Then it forks a log management daemon that opens another FIFO and hangs around waiting for someone to write to it. When a new sudoshell starts, it writes the name of the user who ran it (from SUDO_UID) and its own PID to the first FIFO, then pauses waiting for a signal. Sudoscriptd forks a logger with the information given by sudoshell, which opens yet another FIFO, whose name is derived from the username and PID. The logger then sends the signal that sudoshell is waiting for. Sudoshell then runs script(1) on the session FIFO. The logger takes the output thus produced, tags it with a session ID, and writes it to the log management daemon's (remember him?) FIFO. The log daemon tags the data with a datestamp and writes it to a log file. It also manages the logs so they don't overflow the logging partition. When the user ends her script(1) session, sudoshell tells the front end daemon that it is done. The daemon signals the session logger to wrap up its work, which it does by deleting the session FIFO and exiting.


sudoshell uses sudo(8) to perform all its authentication and privilege escalation. The sudoshell user must therefore be in the sudoers file (See sudoers(5).) with an entry that allows running sudoshell as the desired user. See the SUDOCONFIG file in the distribution for details. (On Linux, this will be in /usr/share/doc/sudoscript-VERSION. Everywhere else, it's in /usr/local/doc/sudoscript-VERSION.)


In a word, no. Giving a user a root shell is a bad idea if you don't trust him or her. There are countless ways to evade the audit trail provided by sudoscript, even without root privilege. Let me highlight the last part of that sentence: even without root privilege! (Think about the implications of the fact that a user must have write access to the logging FIFO to see what I mean.) That means you can't rely on this tool to maintain security for you. So, what good is sudoscript? It's useful in an at least two environments. First, you trust your users, but need a record of what they do for auditing purposes. Second, you may or may not trust your users, but they have successfully agitated for a root (or other) shell. Sudoscript then provides an audit trail as long as your users don't try to evade it.

See the file SECURITY (in the same place as SUDOCONFIG, above) for more on sudoscript's security assumptions.


One optional switch, --datefmt, is accepted by sudoscriptd. This controls the format of the datestamps in the log file. Three options are available.

This selects a long date format of 'wdy mon dd hh:mm:dd ZZZ YYYY' where 'wdy' is the weekday name, 'mon' is the three letter month name, 'dd' is the day of the month, hh:mm:ss' is the local time, 'ZZZ' is the local time zone name and 'YYYY' is the four digit year.

This selects a shorter date format of 'wdy mon dd hh:mm:dd'. This is just the long with the time zone and year removed. short is the default format if no --datefmt is given.

This selects a compressed and numerically sortable format of 'yyyymmddhhmmss'.


The front end fifo is /var/run/sudocript/rendezvous. The backend FIFO is /var/run/sudocript/merge. These two are semi-permanent. The session FIFOs are named /var/run/sudocript/ssd{username}{pid}. They go away once the session closes.

The log file is named /var/log/sudoscript. When the backend daemon rotates the log, it forks a compressor that creates files called /var/log/sudoscript.{n}.gz, where {n} is one through ten. Sudoscriptd stores its PID in /var/run/


The script(1) output is pretty ugly. All control characters are preserved exactly as typed, or worse, as displayed by curses based console apps like vi. The content of such logs can look completely unintelligible unless they are cleaned up first. A shell script from the ``Unix Power Tools'' book that uses sed(1) to do a first pass over such logs is available at I considered building something like that into sudoscriptd, but rejected it for two reasons. First, the daemon needs to get back to reading the FIFO as quickly as possible to avoid losing data to an over-full buffer. Second, any cleanup of the logs would remove information. This could be bad if I were over-zealous in my clean up. As it stands, you can run your own clean up on the log data without destroying the original log.

The datestamp() routine is not locale aware and returns American English values.








sudo -










The following people offered helpful advice and/or code:

   Dan Rich       (
   Alex Griffiths (
   Bruce Gray     (
   Chan Wilson    (cwilson@coNrOp.sSgPi.cAoMm>
   Tommy Smith    (
   Donny Jekels   (


Howard Owen, <>


Copyright 2002,2003 by Howard Owen

sudoscript is free software; you can redistribute it and/or modify it under the same terms as Perl itself.