[Sudoscript-devel] Re: 2.0B testing notes

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

--On Monday, June 10, 2002 05:17:50 PM -0500 Tommy Smith <ts...@ea...> 
wrote:

> Howard:
>
> after a very quick install and run, here is what I'm seeing:
>
> 1) session tags are in the logfile, as noted. this is helpful.
> 2) would be good to have the logfile read such as:
>
> CCYYMMDDhhmmss: {user}:{session} : { script output }
>
Yes, I've thought about this. I'm thinking of making the log format settable
by a command line switch.


> 3) the 'ss' script worked once but it said 'hangup' when trying to
> startup a second session; checked PS and there were several sudoscriptDs
> running.  I probably need to make sure everything else named
> 'sudoscript' is purged so the two versions don't get confused (my
> development stuff isn't running, but might still have files/directories
> - I did remove the old binaries from common $PATHs)

I'd appreciate it if you could follow up on this. Inability to start a 
second
session would be a definite show-stopper for a 2.0 release. Thanks for any
help you can offer.
>
> Adam Morris' idea sounds good - I was thinking that this sort of
> functionality (session logging) should be built into the shell (hello
> SUN?)-

The problem with this is you'd need to hack every shell a user might
choose. Bash source is available, as is source for tcsh, but ksh, sh and
csh are closed source. Also, you'd have to step up to maintaining somewhat
complicated programs across multiple platforms. This would include tracking
changes in the mainline projects. This is a whole lot more than I have time
for. 8)

>        even tried setting 'ss' as $SHELL -- worked fine except for the
> fact that 'script' called itself recursively (!).

Right, script(1) invokes what's in the SHELL envvar. That's why I'm carful
to check that it's in /etc/shell.

>                                                    thinking about making
> an enviroment variable for IS_SUDOSHELL and the 'ss' script could check
> for that & reset the $SHELL to a normal setting to avoid problems. would
> make a login session automatically 'logged'. alias 'exit' to 'exit;exit'
> and it would be transparent.  If each 'session' (user:terminal) had its
> own FIFO then this would handle multiple simultaneous user/terminal
> sessions on one system. (not sure if the 2.0 does that, hadn't gotten
> past the 'hangup' problems here)
>

I assume you are looking for a facility for automatic auditing, rather than
root access. You wouldn't want to force your users to run as root.

One thing this approach would be vulnerable to is running Xwindow apps.
Typing 'xterm' evades your audit trail. Sudo and sudoscript are also
vulnerable to this, of course.

> 4) this brings the point of buffering of the FIFO,  I am wondering if
> there is a way to flush each line and timestamp it as it is written
> to/from the terminal, instead of bulk timestamping them. this would make
> an easier time of determining concurrency of commands issued on the same
> box by multiple users.

Buffering in stdio is controlled by setbuf(3) and its kin. The problem is
that script(1) opens its own channels. You can't get at these from external
code, I don't think. You might be able to find the channels used by 
script(1)
by groveling the kernel ala lsof(8), but changing the buffering would mean
actually diddling the kernel data structures associated with the process.
The only way to do this would be to use your own port of the (BSD derived)
script(1) code. The code is not overly complex, but it uses ptys and other
BSDisms that might be tough to port over to Solaris or Irix, or any other
SysV based platform. That's a big win for using Perl, of course.

The fiendish idea of doing script(1)-like stuff in Perl just occurred to me.
I wonder how much work that would actually be? It would be a 3.0 thing,
if feasible.

What script(1) does is to grab stdin, and pass all output on to the shell,
which it opens in a pipeline. It forks two children. One reads the stdout
of the shell and passes it on to the real stdout. The other copies the
shell's stdout to the  typescript. This sounds like a fun project, once
the killer demo we are getting ready for here is done.
>
> good luck with the development and thanks for the comments/credit.

Thank you for the ideas and the time you are putting in to testing, Tommy.
>
> : )
> TS
>
>



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