[Sudoscript-devel] RE: Architecture 2.0

[Morris, A. <AM...@pr...>]

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.