Thread: [Sudoscript-devel] RE: Architecture 2.0
Brought to you by:
hbo
Menu
▾
▴
sudoscript-devel
|
From: Morris, A. <AM...@pr...> - 2002-05-09 16:20:57
Attachments:
sstest.jpg
|
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. |
|
From: Morris, A. <AM...@pr...> - 2002-05-09 21:48:24
|
Greetings Howard, I'm not entirely sure that we have the same design goals in mind for both of our versions, so don't let me burden your software with my own... :-) I'm not using sudoshell/sudoscriptd and I don't want to install perl everywhere. We're not even using sudo yet, but I need something like sudoshell to be able to persuade management here that it is a better way to go than their current ($30,000 plus $10,000 p.a.) favoured product. My primary goal is to be able to do keystroke logging within a sudo'd shell. Obviously sudoshell/sudoscriptd would do that. On top of that... I would like to be able to generate separate log files for each session. It's easier to find what someone did if I can view a log of the session without having to split a logfile up, trawl through multiple files, or filter out irrelevant data. Some logging should be done through syslog to make it harder for users to hide their tracks. Our current product uses a central logging server, but if the network is down it's useless. I don't want to have any processes running all the time as (I believe) that sudo shell access will be a relatively infrequent occurrence. I would like to be able to selectively turn logging on and off for users. i.e. everyone runs their shell through sudo and it only logs those shells that we actually care about. This should be done at the "write to logfile" end of the process so that the user doesn't know if we are recording their session or not. This is not yet implemented. I don't want to have to have perl everywhere. Not all of our machines have perl on them and we probably can't put it on all of them. (I work in a healthcare organisation and we can't arbitrarily load software on all machines.) The software should be relatively small which makes it easier to eyeball and check that it does what it's supposed to. So far I have it working within 150 lines. If I complete what I currently have it should be no more than 200. Comments included. Maybe 250 to allow for the check of whether we are actually wanting the log output. The single binary version that I have been working on solves most of my issues cleanly and simply. It's easy for someone to escape from keystroke logging but that is true of all keystroke logging that I have seen including that provided by our current solution. Adam -----Original Message----- From: Howard Owen [mailto:hb...@eg...] Sent: Thursday, May 09, 2002 11:36 AM To: Morris, Adam Cc: 'sud...@li...' Subject: RE: Architecture 2.0 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 **************************************************************************** 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. |
|
From: Howard O. <hb...@eg...> - 2002-05-10 00:51:42
|
From where I sit, our goals are convergent over most of the development. I understand where you are going with this, and I don't want to tie you down to my project, but I think we might each be able to get some leverage with each other's code. To be perfectly honest, I'd like a peek at what you are doing so I can compare it to what I'm doing, and maybe steal some good ideas. 8) (Open source is something like folk music in that regard 8) Specifically, I want to rewrite sudoscriptd in C, not so I can ditch Perl, but so I can improve the performance of the daemon. You say you are doing sudoscriptd-like stuff in the single executable. I'm researching the possibility of having just one executable based on your idea. We both seem to have independently arrived at the notion of logging per-session. There's enough congruence that I'd like to get a look at what you are doing. I just had 22 Dell PowerEdge 1650s land on my desk. (Ouch!) so I may not be very responsive over the next week or so. --On Thursday, May 09, 2002 02:48:23 PM -0700 "Morris, Adam" <AM...@pr...> wrote: > Greetings Howard, > > I'm not entirely sure that we have the same design goals in mind for > both of our versions, so don't let me burden your software with my own... > :-) I'm not using sudoshell/sudoscriptd and I don't want to install perl > everywhere. We're not even using sudo yet, but I need something like > sudoshell to be able to persuade management here that it is a better way > to go than their current ($30,000 plus $10,000 p.a.) favoured product. > > My primary goal is to be able to do keystroke logging within a > sudo'd shell. Obviously sudoshell/sudoscriptd would do that. > > On top of that... > > I would like to be able to generate separate log files for each session. > It's easier to find what someone did if I can view a log of the session > without having to split a logfile up, trawl through multiple files, or > filter out irrelevant data. > > Some logging should be done through syslog to make it harder for users to > hide their tracks. Our current product uses a central logging server, but > if the network is down it's useless. > > I don't want to have any processes running all the time as (I believe) > that sudo shell access will be a relatively infrequent occurrence. > > I would like to be able to selectively turn logging on and off for users. > i.e. everyone runs their shell through sudo and it only logs those shells > that we actually care about. This should be done at the "write to > logfile" end of the process so that the user doesn't know if we are > recording their session or not. This is not yet implemented. > > I don't want to have to have perl everywhere. Not all of our machines > have perl on them and we probably can't put it on all of them. (I work > in a healthcare organisation and we can't arbitrarily load software on all > machines.) > > The software should be relatively small which makes it easier to eyeball > and check that it does what it's supposed to. So far I have it working > within 150 lines. If I complete what I currently have it should be no > more than 200. Comments included. Maybe 250 to allow for the check of > whether we are actually wanting the log output. > > The single binary version that I have been working on solves most of my > issues cleanly and simply. It's easy for someone to escape from keystroke > logging but that is true of all keystroke logging that I have seen > including that provided by our current solution. > > Adam > > -----Original Message----- > From: Howard Owen [mailto:hb...@eg...] > Sent: Thursday, May 09, 2002 11:36 AM > To: Morris, Adam > Cc: 'sud...@li...' > Subject: RE: Architecture 2.0 > > > > 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 > > ************************************************************************* > *** 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 |
|
From: Howard O. <hb...@eg...> - 2002-05-09 17:32:52
|
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
|
|
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 |
Thanks for helping keep SourceForge clean.
X