[Sudoscript-devel] RE: Architecture 2.0
Brought to you by:
hbo
Menu
▾
▴
[Sudoscript-devel] RE: Architecture 2.0
|
From: Howard O. <hb...@eg...> - 2002-05-09 18:37:17
|
I'm looking at your single program architecture, Adam. I'm going to protype it in Perl to see if I can hit all my design points using a single script. --On Thursday, May 09, 2002 10:31:26 AM -0700 Howard Owen <hb...@eg...> wrote: > 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 > > _______________________________________________________________ > > Have big pipes? SourceForge.net is looking for download mirrors. We supply > the hardware. You get the recognition. Email Us: ban...@so... > _______________________________________________ > Sudoscript-devel mailing list > Sud...@li... > https://lists.sourceforge.net/lists/listinfo/sudoscript-devel 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 |
