[Sudoscript-devel] RE: Architecture 2.0

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

In my current Perl prototype, the handshake goes like this:

  1  sudoshell is invoked by the user.
  2  if sudoshell isn't root, it reinvokes itself with sudo
  3  sudoshell sends the user's name (from getpwuid or from SUDO_USER env) 
and
     its pid over the main fifo to sudoscriptd.
  4  sudoscriptd stores the username and pid and forks a child to
     handle the session, retaining the child's pid.
  5  the child does a setsid to disassociate from the parent
  6  the child composes a fifo name from the username and ss pid
  7  the child sends this name to ss using the original fifo which it still 
has open.
  8  the child closes the IPC pipe and opens the data pipe
  9  sudoshell runs script on the new pipe
  10 the child manages the log file in the same way that the current 
sudoscriptd does.
  11 the parent periodically chacks extant sessions (using the PIDs it has 
stored)
     and cleans up after defunct sessions. (not implemented yet)
  12 on exit, ss informs the parent sudoscriptd, who uses kill -9 to reap 
the
     disaccociated child.

The child sudoscriptd disassociates from the parent so that it can survive 
problems
with the parent. The child is a long running daemon on its own, so it 
should have
this degree of autonomy. It should also be possible to have the master 
daemon
pick up old sessions started by an earlier sudoscriptd.

The reason sudoscriptd is there in the first place is to manage
the log file size. Since ss is scripting to a fifo, we can move the
log aside without dropping any data, but only in a seperate process.
In the new architecture, the per-session daemon takes on that role, while
the master daemon takes on the new role of session traffic cop.

--On Thursday, May 09, 2002 09:20:56 AM -0700 "Morris, Adam" 
<AM...@pr...> wrote:

>
> Greetings,
>
> 	I didn't see this thread in the archives, but I did see the new
> architecture diagram... :-)
>
> I can see a couple of clarifications that I think need to be made to it,
> and I can probably provide some code already to carry out the best part
> of it.
>
> My current version doesn't generate dynamic logfile/fifo names, and it
> doesn't have all of the error checking that it needs in it, but it's
> getting close.
>
> o.k. Clarifications...
>
> Sudo invokes sudoshell (this is fine, but what if you're just running
> sudoshell manually, as I run sstest... :-)
>
> Sudoshell opens a named pipe to sudoscriptd and announces its presence.
>
> Sudoscriptd should then generate a new fifo name, and pass that back to
> sudoshell before forking.  Or Sudoshell should pass a generated fifo name
> to sudoscriptd before it forks.
>
> Sudoshell then invokes script with the fifo as its output.  Suggestion...
> if you're still going with a two process model then sudoshell should
> fork, the parent should wait and the child can exec script.  The parent
> will receive a SIGCHLD when the child dies and can then send a clean up
> message to the sudoscriptd.
>
> I already have (as stated below) a partially complete, working, but not
> yet usable C program that does the majority of this.  I have done away
> with the daemon as I don't feel that I need the overhead of running it
> all the time. Instead I have the following architecture.
>
> Any comments?
>
> Adam
>
> -----Original Message-----
> From: Howard Owen [mailto:hb...@eg...]
> Sent: Wednesday, May 08, 2002 5:36 PM
> To: Morris, Adam
> Subject: RE: http://www.egbok.com/music.html
>
>
> Hey, cool! I've been considering a C rewrite in connection with a
> "2.0" version that would create separate FIFOs per session. That
> way you could track individual users which current isn't possible
> with sudoshell. I have a sudoscriptd that forks a child when
> contacted by sudoshell. The child creates a new FIFO based on the
> userid and pid that sudoshell sends. It then sends the name of the
> FIFO back to sudoshell, closes it, and opens the new one. Sudoshell
> closes its end of the first FIFO, then runs script on the new one.
> I was considering a C rewrite for sudoscriptd for performance reasons.
> (Mainly reducing memory overhead of the Perl interpreter.) The advantage
> of Perl is that it's a lot easier to do sophisticated stuff in a few
> lines of code. I've also viewed it as a portability aid, since the
> various Unices have varying degrees of POSIX compliance. But the
> advantage of not needing a Perl install balance that somewhat.
>
> There's a sudoscript-devel mailing list at
>    	   http://lists.sourceforge.net/lists/listinfo/sudoscript-devel
> I'm cc'ing the list on this reply. Why don't we discuss what you are
> doing  there,
> then open up a CVS module at sourceforge for a C rewrite?
>
> --On Wednesday, May 08, 2002 03:37:01 PM -0700 "Morris, Adam"
> <AM...@pr...> wrote:
>>
>> I hope that you don't mind, but I'm currently in the process of rewriting
>> sudoshell in C.  It's not an exact rewrite, it's more of an "nice idea,
>> but I want to..." rewrite.  My version is about half way there (it's
>> functional but not yet useful) and still uses script.
>>
>> It checks that $SHELL is set to a valid shell, and then forks, the parent
>> creates a fifo, sends a signal to the child and then logs all output from
>> the fifo into a logfile (a separate logfile for each session).  The child
>> waits for the signal and then runs script to the same fifo.  When the
>> child dies the parent catches the signal, closes and removes the fifo and
>> closes the logfile.
>>
>> I've got to improve the error checking a bit and add in the functions to
>> generate the fifo name (before the fork) and the logfile name.  This
>> should allow for per session log files.  The big advantage (for me) of a
>> C version is that I don't need to have perl on every machine, and we
>> don't.  As it creates its own version of the daemon that you have as a
>> separate process it doesn't need to be running when it's not needed.
>>
>> So far the same source runs unmodified (and without any conditional code)
>> on Linux and HP-UX.  I'm hoping that I'll be able to get it running on
>> AIX and Solaris without too much (any?) modification.  Then hopefully I
>> can persuade our security section to drop the idea of paying $30,000 plus
>> $10,000 per annum for a commercial product that does essentially the same
>> thing.  (It has a nicer web front end... big deal).
>>
>> Adam
>>
>
> 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
>
> *************************************************************************
> *** This message is intended for the sole use of the individual and
> entity to whom it is addressed, and may contain information that is
> privileged, confidential and exempt from disclosure under applicable law.
> If you are not the intended addressee, nor authorized to receive for the
> intended addressee, you are hereby notified that you may not use, copy,
> disclose or distribute to anyone the message or any information contained
> in the message.  If you have received this message in error, please
> immediately advise the sender by reply email and delete the message.
> Thank you very much.
>
>



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