Date: Thu, 24 Sep 92 15:15:14 EST From: The Moderator (Mike Muuss) To: UNIX-WIZARDS@BRL.MIL Reply-To: UNIX-WIZARDS@BRL.MIL Subject: UNIX-WIZARDS Digest V16#018 UNIX-WIZARDS Digest Thu, 24 Sep 1992 V16#018 Today's Topics: Re: mv -----filename----- Intro to comp.unix.wizards - read before posting! (weekly announcement, last change: Jul 31 10:30) Re: Why does SIGPIPE exist ? (and how to work around it?) Re: How to intercept UNIX system calls ? Re: Locking out users Gnode and SVC Errors... Re: ``TradpDoor'' Algorithm Re: Robin Hood and Fryer Tuck (was: Locking out users) ----------------------------------------------------------------- From: Tomas Nopp Subject: Re: mv -----filename----- Date: 18 Sep 92 13:49:57 GMT Sender: news@eua.ericsson.se Nntp-Posting-Host: euas20c02.eua.ericsson.se To: unix-wizards@sem.brl.mil semerz@lmcp.jussieu.fr (Michel T. Semertzidis) writes: >Dear Wizards >I want to move a file named "-----anyname-----" >Any hint?? Sure.... use mv which is a command to move/rename files. mv oldname newname : mv foo.bar foo.bar.new mv file(s) newplace(directory) : mv foo.bar ../Anotherdirectory mv oldname newplace/newname : mv foo.bar ../Anotherdirectory/foo.bar.new Does it help ??? Also.... try man mv >Thanx in advance.. youre welcome... _________________ __________ / _ , /l / _/__()_/))_(/_/)_ _/ L/_()_/)_/)_ / / ******************************************************************** * Tomas Nopp Tel : +46 8 727 33 24 * * Ellemtel telecom labs Fax : +46 8 647 80 59 * * Box 1505 Email : Tomas.Nopp@eua.ericsson.se * * S-125 25 ALVSJO <------ Snailmail * ******************************************************************** ----------------------------- From: Brian Fitzgerald Subject: Intro to comp.unix.wizards - read before posting! (weekly announcement, last change: Jul 31 10:30) Date: 20 Sep 92 10:00:43 GMT Expires: Tue, 20 Oct 1992 10:00:24 GMT Followup-To: poster Nntp-Posting-Host: mml0.meche.rpi.edu To: unix-wizards@sem.brl.mil Please take a moment to read this before posting to comp.unix.wizards for the first time. comp.unix.wizards is for in-depth discussion of advanced unix topics. Elementary questions do not belong in comp.unix.wizards. Although some socket questions (for example) are appropriate, "How do I program with sockets?" is not. Crossposting to comp.unix.wizards and comp.unix.questions is inappropriate. Plenty of wizards read comp.unix.questions and answer questions there. A wizard is someone who can rewrite the entire system from scratch. If you are not a wizard, you are welcome to follow along the discussions anyway. You'll learn quite a bit about how UNIX works. Caution: post to wizards only if you are yourself a wizard. For a list of answers to frequently asked questions (FAQ), please refer to comp.unix.questions (or comp.lang.c, news.answers, etc...). "How do I delete a file whose name starts with a '-' ?" is an example of such a question. Please do not ask or answer FAQ's on the net. Write to Unix-Wizards-Request@BRL.MIL (Subject: subscribe. Any message.) if you want a daily digest of this newsgroup mailed to you. To unsubscribe from the unix-wizards mailing list, send mail to Unix-Wizards-Request@BRL.MIL Subject: unsubscribe. It is incorrect to post such requests to the list, or to mail them to me, though others may mistakenly do so. E-mail comments about this posting are welcome. From time to time I'll summarize them. Brian -- These opinions are mine, and do not necessarily reflect those of any academic department or computing service at Rensselaer. ----------------------------- From: Avinash Chopde Subject: Re: Why does SIGPIPE exist ? (and how to work around it?) Date: 20 Sep 92 20:32:37 GMT Sender: news@contex.contex.com To: unix-wizards@sem.brl.mil In article <2966@contex.contex.com>, avinash@felix.contex.com (Avinash Chopde) writes: > ... (lines deleted, I asked why does write to a closed pipe send a signal instead of just having write() return an error code - EOF or otherwise). I received many replies suggesting that behavior is exactly what a filter program needs. But that seems an excessive solution to a simple problem --- either the OS could just throw way the characters, or the filter program could be coded to check the return value of the write() call and act accordingly. As to a specific example where I need this: I have this "large" GUI program that needs to start up another process (a "forms" editor) as part of some command. The "large" process write()'s to the "forms" editor. Now, the user may for some reason terminate the forms editor, and it should allow the main process to continue gracefully by detecting the closed pipe, and continuing on to whatever else the user may want to do. I can also imagine this being required when a GUI shell (!!!) is built for UNIX. Of course there are a few around, and maybe all everybody does is to SIG_IGN the SIGPIPE signal. I wanted to keep the code clean of signal handling, after all signals denote some extraordinary condition, and the default action is almost always appropriate. But SIGPIPE seems to be an overkill (Why doesn't the reader get a SIGPIPE too ?). -- --------------------------- Avinash Chopde office : 617 246 1776x5582 avinash@contex.com (...!uunet!contex!avinash) ----------------------------- From: Pauli Dale Subject: Re: How to intercept UNIX system calls ? Date: 20 Sep 92 22:06:18 GMT Sender: news@cs.uq.oz.au To: unix-wizards@sem.brl.mil imtst@pitt.edu (I-ming Tsai) writes: > I am trying to intercept the UNIX system calls. The following simple > program works by itself: [code deleted] > When I tried to substitute the system calls with my own functions, > I wrote the following simple program: >==================== myfunction.c ========================= >open(path,flags,mode) >char *path; >int flags,mode; >{ >printf("This is my open!\n"); >return(1); >} >write(fd,buff,nbytes) >int fd,nbytes; >char buff; >{ >printf("This is my write!\n"); >return(2); >} >close(fd) >int fd; >{ >printf("This is my close!\n"); >return(3); >} >===================== end of myfunction.c ====================== The printf's are never going to output anything since the file handling code is calling write() to output the stuff and you've patched write. I solved this problem four to five years ago (while implementing a remote fork as part of a project). My solution was quite involved since I was trying to maintain lots of compatibility constraints and I wasn't allowed root access and we didn't have the source code for the kernel/libraries available! (dispite these setbacks we still got the thing going!!!) Back to the real content of my message: First, you create lots of little routines with the same names as the system calls you are replacing (e.g. open, write, close) and they all have the form: close(fd) int fd; { whatever you want done before the close Close(fd) whatever you want done after the close } The important thing being the Close with a capital C. This routine is an alias for the existing system call close. Close cannot call close since that would be naughty endless recursion. It should be possible to have the Close routine simply call close and link in the necessary bits of the standard library but I never worked this one. My solution, was to unpack the standard library (it is an ar format archive on most machines) and to patch the binary files produced. Finally archive all the capitalised system calls and all of my patched versions into a new library. Link all your programs with the final library and they have major problems telling if they are running under the patched system or not. In the remote fork case, all the calls checked if they should be made on the local host or the originating host and dispatched accordingly. I think I've still got the code/writeup on tape somewhere. If anybody is really interested in seeing it, I can probably dig it up. Pauli Paul Dale | Internet/CSnet: grue@cs.uq.oz.au Dept of Computer Science| Bitnet: grue%cs.uq.oz.au@uunet.uu.net Uni of Queensland | JANET: grue%cs.uq.oz.au@uk.ac.ukc Australia, 4072 | EAN: grue@cs.uq.oz | UUCP: uunet!munnari!cs.uq.oz!grue f4e6g4Qh4++ | JUNET: grue@cs.uq.oz.au -- ----------------------------- From: A Wizard of Earth C Subject: Re: How to intercept UNIX system calls ? Date: 21 Sep 92 05:32:50 GMT Sender: news@fcom.cc.utah.edu To: unix-wizards@sem.brl.mil In article <6049@blue.cis.pitt.edu.UUCP> imtst@pitt.edu (I-ming Tsai) writes: [ ... program named "test" linked against something with a "write" function that calls "printf" ... ] >write(fd,buff,nbytes) >int fd,nbytes; >char buff; >{ >printf("This is my write!\n"); >return(2); >} 1) Is "test" a built-in in the shell you are using? 2) Is your path set up so it executes binaries in "." before "/usr/bin"? 3) How does "printf()" finally do it's output... is it by calling the "write()" system call (which you have provided an alternate definition that calls "printf()" that calls "write()" ...)? 4) Doesn't write take a character pointer rather than a single character as a parameter? Try again, using: #include write( fd, buf, cnt) int fd; char *buf; int cnt; { char *str = "This is my write!\n"; realwrite( 0, str, strlen( str)); } realwrite( fd, buf, cnt) int fd; char *buf; int cnt; { return syscall( SYS_write, fd, buf, cnt); } ...Fix the other "system call replacements" similarly. Terry Lambert terry_lambert@gateway.novell.com terry@icarus.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. -- ------------------------------------------------------------------------------- "I have an 8 user poetic license" - me Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial ------------------------------------------------------------------------------- ----------------------------- From: Murray Nesbitt Subject: Re: How to intercept UNIX system calls ? Date: 21 Sep 92 09:08:51 GMT Sender: Murray Nesbitt Followup-To: comp.unix.questions To: unix-wizards@sem.brl.mil imtst@pitt.edu (I-ming Tsai) writes: > I compiled them (under Sun 4/470 running SunOs 4.1.2) using > > cc -o test test.c myfunction.c > > I executed the "test", but got nothing. It didn't print my strings > on the screen. Any help ? Thank you in advance ! Don't name your program ``test''. When you go to run it, you are likely running a shell builtin named ``test'', or possibly ``/bin/test''. I've directed followups to comp.unix.questions, as this is not wizardly. -- Murray ----------------------------- From: Chris Metcalf Subject: Re: Locking out users Date: 21 Sep 92 14:51:35 GMT Sender: news@mintaka.lcs.mit.edu To: unix-wizards@sem.brl.mil Dan Bernstein writes (with respect to disabling accounts): >[The user] can, for instance, set up a server of his own on a TCP port. Or he >can arrange for programs to be run through cron, perhaps accepting >commands from the outside by some mechanism. Or he can set up a .forward >which executes commands for him. Or he can set up a setuid program and >get someone else to run that program. If you don't shut down _all_ of >these mechanisms then you haven't really shut down _any_ of them. These are all good points, though most of them are more general than the issue of how to delete an account (i.e., setting the shell to be bogus, the password to be '*', deleting the account completely, etc.). A careful admin should certainly kill all the user's jobs running on all the machines the user had accesss to and delete all private atjobs and crontabs. The account should be locked with chown root/chmod 700, or deleted completely, and you should find and assess any files owned by that user elsewhere in the filesystems he or she had access to. All of these issues are important no matter what user-lockout technique is used. The .forward issue is one that is relevant with respect to disabling vs. deleting a given account; the administrator should ensure that the user's .forward does something valid if the account is merely disabled. (In our case, we scan .forwards every night and do a validity check anyway, for inclusion in our global aliases file.) Note that sendmail typically has no problem reading a user's .forward even if it is under a root-owned 700-mode home directory. Thanks for some good worst-case suggestions on how a user can avoid being shut down, Dan. -- Chris Metcalf, MIT Laboratory for Computer Science metcalf@lcs.mit.edu // +1 (617) 253-7766 ----------------------------- From: cdmitchell@vax1.umkc.edu Subject: Gnode and SVC Errors... Date: 21 Sep 92 14:58:21 GMT Sender: Parsifal Administration To: unix-wizards@sem.brl.mil As of late, process creation on my DECstiation 5000/200 running Ultrix 4.2A yields the following errors: getsvc: stat of /etc/svc.conf failed getsvc: stat failed: File table overflow ldopen: cannot open /vmunix Very odd...no file system is near full...not running out of inodes either. A reboot temporarily relieves the problem, but by nightfall, it is back full force. Other bizarre errors have recently complained about a lack of "gnodes." Could it all be related? Why is there no mention of "gnodes" in the docs or any other U*ix related books? Please help (if you can). Chris Mitchell cdmitchell@vax1.umkc.edu ----------------------------- From: Mark Allen Kampe Subject: Re: ``TradpDoor'' Algorithm Date: 21 Sep 92 15:24:01 GMT NNTP-Posting-Host: pongo.west.sun.com To: unix-wizards@sem.brl.mil I believe that UNIX just uses the DES - about which you should have no trouble finding articles. It was hot stuff in the 79-82 time frame. Go look through old issues of CACM/Spectrum for discussions of the DES. By way of brief summary, it is a block encryption technique that involves several cycles of exclusive ORing, shifting and bit swapping. As to non-reversability however, I believe the algorithm is its own inverse (although I will surely be flamed to death if I am wrong). DES(key,DES(key,data)) = data ----------------------------- From: Tim Hoogasian Subject: Re: Robin Hood and Fryer Tuck (was: Locking out users) Date: 23 Sep 92 20:56:00 GMT Sender: news@alc.com Nntp-Posting-Host: prez To: unix-wizards@sem.brl.mil In article smr@hitkw14.pki-nbg.philips.de (S.Riehm) writes: >Also, out of interest, does anyone have the post about these two >programs, I remember them being posted some time ago (ie: 1988?), from >memory there were two programs watching each other, and when one was >killed, a message like: "Help me robin" would appear on the console, >and then the robin process would create a new fryer tuck process and >so on. well, i don't have the programs themselves, but as i recall the story of this went thru rec.humor and/or rec.computers.folklore (or somesuch). the story was written by a fellow who'd been a roommate of one of the original "pranksters". the (daemon) processes were written for a Honeywell computer system, and the hackers had access to the source code. basically, the programs were written to get the attention of the manufacturer, in order for them to fix an enormous security problem. anyway, if folks are interested, i could dig around and post the story. it's hilarious. when i first read it (and even now!) i was almost literally rolling on the ground, eyes watering, from laughter! ;-) -tim -- ========================================================================== #define DISCLAIMER "I don't even represent myself, much less anyone else!" Internet: hoogs@alc.com | UUCP: ...!netcom!alc!hoogs | Tel: (408) 943-0630 ========================================================================== ----------------------------- End of UNIX-WIZARDS Digest **************************