Path: utzoo!utgpu!watmath!clyde!att!rutgers!apple!claris!ames!haven!ncifcrf!nlm-mcs!adm!xadmx!postmaster@nusc.arpa From: postmaster@nusc.arpa (SMTP MAILER) Newsgroups: comp.unix.wizards Subject: Mail not delivered yet, still trying Message-ID: <17681@adm.BRL.MIL> Date: 1 Dec 88 19:29:32 GMT Sender: news@adm.BRL.MIL Lines: 1287 ----Mail status follows---- Have been unable to send your mail to , will keep trying for a total of three days. At that time your mail will be returned. ----Transcript of message follows---- Date: 1 Dec 88 07:19:00 EST From: Subject: UNIX-WIZARDS Digest V6#035 To: "baynes" Received: from SEM.BRL.MIL by nusc.arpa with SMTP ; Thu, 1 Dec 88 07:18:41 EST Received: from SEM.BRL.MIL by SEM.brl.MIL id aa04903; 1 Dec 88 3:18 EST Received: from sem.brl.mil by SEM.BRL.MIL id aa04864; 1 Dec 88 2:45 EST Date: Thu, 01 Dec 88 02:45:33 EST From: The Moderator (Mike Muuss) To: UNIX-WIZARDS@BRL.MIL Reply-To: UNIX-WIZARDS@BRL.MIL Subject: UNIX-WIZARDS Digest V6#035 Message-ID: <8812010245.aa04864@SEM.BRL.MIL> UNIX-WIZARDS Digest Thu, 01 Dec 1988 V6#035 Today's Topics: Re: random passwords (was Re: Worm...) Re: Mounting floppies Re: Ghost file Need news feed (pref. in DC area) Re: Autologout of unused terminals ioctl in perl (was: using System V 'cu') Re: what is the 'l' permission? Re: cat -u Re: umlaut Re: Insecure hardware (was Re: gets(3) nonsense) Re: The Internet Virus--Another issue Re: 4.3 BSD networking bugs Software Quality (was: Re: rtm and uucp) Re: Worm/Passwords Echo Re: Autologout of unused terminals Re: fixing rm * (was: Worm/Passwords) Re: Here's a *BRILLIANT* password idea! (Sarcasm on) Re: "tip" leaves device file exclusively open Re: Autologout of unused terminals Re: wakeup() race condition. (theory) Afio faster than Cpio??? Re: Ghost file Why's and wherefore's..... Re: Mounting floppies Re: Autologout of unused terminals Re: rm etc. (was: Nasty Security Hole?) Re: wakeup() race condition. (theory) Re: ioctl in perl (was: using System V 'cu') Re: Predictable Re: what is the 'l' permission? Re: Re: The Internet Virus--Another issue ----------------------------------------------------------------- From: Larry McVoy Subject: Re: random passwords (was Re: Worm...) Date: 30 Nov 88 02:22:04 GMT Sender: news@sun.uucp To: unix-wizards@sem.brl.mil Steve wrote: >>Let's look at this quantitatively. There are, more or less, 95 >>printable characters. We'll subtract 2 for @ and #, which many UNIX Barry said: [wonderful] Jeez. This sounds awful. Try this instead, you'll like it better. Add a field somewhere (/etc/failures?) that records the number of failed attempts. If it reaches some maximum, disallow logins with some message like: ("Possible security risk: %d failed attempts\n", failed) If the failed number is greater than MAXFAIL/2, then warn the user that he ought to reset his password (to anything, including what it was). Resetting would clear the failed field. Now that I think about it, you could print out the number of failed attempts to date at login time. Users would know right away if someone had been beating on their account. Wouldn't this be a much easier and more palatable way to solve the problem? Larry McVoy (lm%snafu@sun.com) ----------------------------- From: Stefan Stapelberg Subject: Re: Mounting floppies Date: 29 Nov 88 10:10:52 GMT To: unix-wizards@sem.brl.mil In article <5682@louie.udel.EDU> law@udel.EDU (Jeff Law) writes: >suid programs are not the only problem with allowing users to mount floppies, >what is going to stop me from putting my floppy in the drive and saying >mount /dev/floppy /etc I think, it is just that easy to write a small C program which checks wether the user doing the mount is the owner of the mounting point. BTW: You not only have to look for suid-files, but also for special device files! In Germany, there is a law for government agencies when accessing sensitive data (e.g. personal data): The sensitive data has to be physically present only when someone is working with it. So people like it to mount the floppy disk rather than read/write tar archives. -- Written (W) 1988 by Stefan Stapelberg Phone: +49 9352 5948 ----------------------------- From: DAVID NEWALL Subject: Re: Ghost file Date: 25 Nov 88 12:11:13 GMT Keywords: ghost, unprintable, unlink To: unix-wizards@sem.brl.mil I had an off by one bug in a "high level" file access library, once. It's effect was to append a single character (usually > 127) to the end of all files created. Needless to say, I couldn't generate the filename from within the shell, and so I couldn't delete it using rm. But it turned out to be easy, to write a C program to delete the file. It looked sort of like this: main() { char name[] = "badfile?"; name[7] = (char) 255; unlink(name); } Of course, I had to use "od" to find out the value of the `bad' character. (Ls, by default, displays unprintable characters as "?"). -- David Newall Phone: +61 8 343 3160 Unix Systems Programmer Fax: +61 8 349 6939 Academic Computing Service E-mail: ccdn@levels.sait.oz.au SA Institute of Technology Post: The Levels, South Australia, 5095 ----------------------------- From: storm development account Subject: Need news feed (pref. in DC area) Date: 30 Nov 88 03:36:01 GMT Keywords: dc news feed To: unix-wizards@sem.brl.mil Greetings, If this is a repost, my apologies. Looks like the regional distribution only sent it to the source machine! I have a client, (The Process Control Divison of the U.S. Postal Service) that is looking for a Usenet mail connection and a news feed. They can handle 2400 bps or 9600 bps if its being sent with a U.S. Robotics HST 9600 modem. They should also be able to serve as a feed for a couple of other sites. If you can provide a feed, or know of someone who can, please let me know. (Might even be able to set up Empire on their system!) Thanks, Storm -- If you're going to walk on thin ice, uunet!reign!storm You might as well dance... ----------------------------- From: Bjorn Engsig Subject: Re: Autologout of unused terminals Date: 29 Nov 88 15:48:19 GMT To: unix-wizards@sem.brl.mil In article <201.nlunix6@orcenl.uucp>, I asked > Is there any way to see if a terminal has not been used for some time, [ ... ] Thank you to all of you who send me a mail, or posted a followup. I've got plenty of ideas and pointers to existing software. Now, we can all just watch the ongoing discussion, whether one should have such a mechanism in the first place :-) -- Bjorn Engsig, ORACLE Europe \ / "Hofstaedter's Law: It always takes ..!uunet!mcvax!orcenl!bengsig X longer than you expect, even if you phone: +31 21 59 56 411 / \ take into account Hofstaedter's Law" ----------------------------- From: Larry Wall Subject: ioctl in perl (was: using System V 'cu') Date: 30 Nov 88 06:51:33 GMT To: unix-wizards@sem.brl.mil Leslie Mikesell writes: : Perhaps the reason is that it is not compiled into the official AT&T : release, at least not up to SysVr3.1 on the 3B2's. It would be extremely : useful, though, as would the ability to execute a script like that : found in the Dialers file at an arbitrary time (i.e. after the connection : is made). The code is obviously already there. Is Larry Wall listening? : How about adding ioctl() to perl so we can use it instead? Er, um, that's kinda hard. But I been thinkin' about it. In the meantime, if it's something that stty knows about you can just fork one off to do whatever you want after making sure you have the tty open on stdout (stdin on some systems). open(TTY,"/dev/tty07"); ... open(dupout,">&stdout"); # dup stdout close stdout; open(stdout,">&TTY"); # dup filehandle TTY system 'stty', '-echo', 'raw'; close stdout; open(stdout,">&dupout"); # restore stdout close dupout; If efficiency isn't as important you can just say system 'stty -echo raw >/dev/tty07'; To do ioctl in perl I'd have to have a way to supply variable sized 3rd arguments to ioctl. I figure I could do that with a pre-sized array, with extra information to say whether it is to be interpreted as bytes, shorts or longs. A scalar could likely substitute for a single element array. The main problem with doing ioctl in perl is not the 3rd argument as much as the 2nd. Have you looked at the shenanigans they do in sys/ioctl.h? (On BSD and Sun at least--I don't know about Sys V.) Those cute little identifiers you feed to the 2nd argument are awful. You say, in C, something polite like: ioctl(0,FIONREAD,&cnt); and cpp turns that into the following mishmash ioctl(0,(0x40000000|((sizeof(int)&0x1fff)<<16)|('f'<<8)|127),&cnt); So if I'm gonna let you write, in perl, ioctl(stdin,$FIONREAD,$cnt); I've gotta have some way of teaching perl about the gobbledygook above. Anyway, I'm thinking about it. Adding chroot() would be much easier. And maybe getppid(). I think I'll make the current priority a variable, usable only if your system supports getpriority/setpriority: $" -= 20; # grab that CPU! The nice program could then be written like this: #!/usr/bin/perl $diff = ($ARGV[0] =~ s/^-(-?\d+)/$1/) ? shift : 10; $" += $diff; exec @ARGV; Is this reasonable? I'm still thinking about that ioctl... Larry Wall lwall@jpl-devvax.jpl.nasa.gov "So many programs, so little time..." ----------------------------- From: Henry Spencer Subject: Re: what is the 'l' permission? Date: 29 Nov 88 19:31:57 GMT To: unix-wizards@sem.brl.mil In article <516@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes: >>Consider a program that mandatory-locks /etc/passwd and then sleeps forever. >>... >Well, actually, in order to lock out reads, you have to establish a >write lock on the region in question, and to establish a write lock you >need to have a file descriptor open for writing... Hmm, guess I should have read the documentation! :-) At at least one point in the past, for at least one of the locking schemes (/usr/group?), locking /etc/passwd *was* a problem and hence the 'l' bit. >In AT&T's documentation, they appear to recommend that you not use >mandatory locking because there's extra overhead on every read or write >performed... One can always argue that a more efficient implementation could largely fix this. -- SunOSish, adj: requiring | Henry Spencer at U of Toronto Zoology 32-bit bug numbers. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu ----------------------------- From: Henry Spencer Subject: Re: cat -u Date: 29 Nov 88 19:41:10 GMT To: unix-wizards@sem.brl.mil Organization: U of Toronto Zoology Lines: 9 In article <4864@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > /bin/cat -uv "$file" | /usr/ucb/more -10d > >I couldn't get it to work right without the -u option. This is a bug (albeit a long-standing and widespread one) in your cat. -- SunOSish, adj: requiring | Henry Spencer at U of Toronto Zoology 32-bit bug numbers. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu ----------------------------- From: Clay M Bond Subject: Re: umlaut Date: 30 Nov 88 11:24:03 GMT To: unix-wizards@sem.brl.mil Peter Salus: > . . . and tjhat the posters are ignorant. Aren't they, though? -- << ***************************************************************** >> << Clay Bond -- IU Department of Leath-er, er, uh, Linguistics >> << bondc@iuvax.cs.indiana.edu AKA: Le Nouveau Marquis de Sade >> << {pur-ee,rutgers,pyramid,ames}!iuvax!bondc *********************** >> ----------------------------- From: Chris Torek Subject: Re: Insecure hardware (was Re: gets(3) nonsense) Date: 30 Nov 88 11:42:19 GMT Followup-To: comp.unix.wizards To: unix-wizards@sem.brl.mil Someone else mentioned the correct answer, but I suppose I had best do it again. I have redirected followups to comp.unix.wizards only. >In article <1189@cps3xx.UUCP> rang@cpswh.cps.msu.edu (Anton Rang) `corrects' me: >>VAX processors do have separate bits for read, write, and execute on >>each page (I seem to vaguely recall one more). ... In article <3335@tekcrl.CRL.TEK.COM> terryl@tekcrl.CRL.TEK.COM writes: > BBBBUUUUUZZZZ!!!!! Wrong answer... So far so good.... > The VAX only has read/write permissions per page, but it does have >4 different access modes per page (kernel, executive, supervisor, & user), >with each access mode having its own independent permissions per page... Not so. There is a four bit field for `access control'. With four CPU modes (K E S & U as above) and two permissions (R & W), there are only half as many bits as needed for fully independent permissions. Instead, the VAX designers made the assumption that if the user can write the page, all the more privileged modes should also be able to write; if the user can only read, more bits might allow other modes to write. Whatever permissions a less-privileged mode has, a more- privileged mode has at least those permissions. 4BSD VAX Unix makes use of only the following modes: #define PG_NOACC 0 #define PG_KW 0x10000000 #define PG_KR 0x18000000 #define PG_UW 0x20000000 #define PG_URKW 0x70000000 #define PG_URKR 0x78000000 Execute permission is implied by read permission. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris ----------------------------- From: Mike Klaus Subject: Re: The Internet Virus--Another issue Date: 29 Nov 88 17:28:55 GMT To: unix-wizards@sem.brl.mil Today's Score: Crossover 1 LineEater 0 And, if you have an unauthorized copy of jay's mailer, it'll crash @ *the end* of the previous line. Who says that software can't be reposessed? mak BTW, to all those that have fingered my new password, it's poison. ----------------------------- From: Chris Torek Subject: Re: 4.3 BSD networking bugs Date: 30 Nov 88 13:18:09 GMT To: unix-wizards@sem.brl.mil In article <204@hsi86.hsi.UUCP> stevens@hsi.UUCP (Richard Stevens) writes: >(1) When using UNIX domain datagrams, only the first 14 bytes of > the sender's socket address are passed with the datagram. > It looks like sbappendaddr() ... Yep. Fixed in 4.4BSD? (4.4 will have variable length socket addresses, which are required by various ISO protocols.) >(2) When using XNS datagrams (IDP protocol) you have to explicitly > call bind() to assign an address to yourself, if you want > the other end to be able to respond to you, otherwise an all > zero address gets sent along with the datagram. spp_usrreq calls ns_pcbbind with a null `nam', telling it to choose a local port. ns_pcbbind defers choosing a local host address, however, until send time, just like the TCP code. Alas, ns_output does not contain the `#ifndef notdef' (=~ `if true') code that appears in ip_output.... -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris ----------------------------- From: "Snoopy T. Beagle" Subject: Software Quality (was: Re: rtm and uucp) Date: 29 Nov 88 23:48:09 GMT Followup-To: comp.software-eng To: unix-wizards@sem.brl.mil In article <1988Nov15.180821.20324@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: | The popular software distribution from a certain | university in southern California is a good example of interesting ideas | often marred by first-cut [i.e. poorly thought out, messy, sometimes | incomplete] designs and implementations. | This is not to say that any random commercial organization, like, say, | one whose name has three initials and an "&" in it, will *necessarily* | do better. But those people can, in theory, afford to spend some money | on quality assurance. Universities generally can't. Does this mean I should "rm -rf cnews" rather than trying to get it to build? :-) Can I trust software from a certain university in eastern Canada? :-) These days, a vender is likely to be pushing both hardware and software out the door as soon as possible so that they can rake in the bucks for whizzy new feature foobar before their competitor beats them to it. They may very well argue that they can't spend any more time/money on quality. If you want better quality, you need to get customers to demand it. Customers with large budgets. It isn't who you work for, it is your state-of-mind that counts. Tools like code inspections can help, but they may not buy you much if you're just going through the motions. _____ /_____\ Snoopy /_______\ |___| tektronix!tekecs!sopwith!snoopy |___| sun!nosun!illian!sopwith!snoopy ----------------------------- From: Jordan Brown Subject: Re: Worm/Passwords Date: 30 Nov 88 12:56:14 GMT To: unix-wizards@sem.brl.mil jbayer@ispi.UUCP (Jonathan Bayer) writes... > In article <10@herron.uucp>, jbrown@herron.uucp (Jordan Brown) writes: > > jbayer@ispi.UUCP writes: > > > It is possible to adopt a single system, if that system is random. For > > > example, I have included below a random password generating program, ... > > Somebody go by this fellow's office and look at all the desk blotters and > > scraps of paper to find written-down passwords. Then log in and mail him > > a note to go watch War Games. > Instead of being critical without offering suggestions, why don't you > shut up? You may disagree with me on the security of randomly generated passwords, but I don't think this tone is reasonable. (At least I don't think my comment was this nasty. My apologies if it came across that way.) > I challenge you to develop a program which will create random passwords > which will be easy to remember. I'm not sure what "easy to remember" means. Enough users have problems remembering passwords that *they* picked to make me doubt that any random scheme has any chance. I didn't mean to say that *your* random password program was bad, but that they *all* are. I'm not going to try to write a "better" version, as I'm convinced it isn't possible to write one "good enough". > If you do this then you will have contributed > something worthy to the net instead of useless abuse. Again, I did not intend abuse. Randomly generated passwords are the "obvious" answer to the problem of easily-guessed passwords, but cause their own brand of security hole (which is probably worse, as it doesn't take the same level of ingenuity to exploit it). Random passwords make life more awkward for the user while possibly *reducing* security. Thinking about it, there's another serious problem. If you don't have a *very* good seed source, your random passwords are easily guessable. (For instance, suppose you use the time in seconds as your source. if you know what day the password was assigned, then there are only 86k passwords to try. It'll typically take a second or so to try each, so about a day of CPU time later... Time in ms would be better, but it is still probably practical to observe password changes and search the appropriate range of random numbers. Write a program that "watches" /etc/passwd and logs username and time when it's updated. Probably an adequate solution is to continuously increment a counter while waiting for a keystroke. That's pretty close to truly random.) You presented a "solution" to the problem; I poked what I consider to be a gaping hole in it, one that I thought was "well-known" (documented in a mainstream motion picture, even). I hate a flawed solution to a problem more than no solution at all. At least when you know there's no solution you aren't deceived. Sorry if I've offended; I just don't think random passwords are a viable answer. (You'd probably figured that out. :-) ----------------------------- From: Kenneth Almquist Subject: Echo Date: 30 Nov 88 14:18:11 GMT To: unix-wizards@sem.brl.mil I've been implementing a public domain shell and I'm wondering what to do about the echo builtin. The System V echo command interprets a number of escape sequences (e.g. \n for newline) which the BSD echo does not, so I can... 1. Implement the System V echo on the grounds that it will make it easier to run System V shell scripts. 2. Implement the BSD echo on the grounds that it's the "right" approach (since the System V echo is useless if you want to echo an arbitrary string unchanged). 3. Don't provide an echo builtin, so users get whatever echo command is installed in /bin. This follows the principle of least surprise, but it makes shell scripts run slowly and does nothing for portability. Any suggestions? In particular I would like to know if any standards organizations have addressed the semantics of echo. Does anyone know what the merged AT&T/SUN UNIX is going to do about echo? Kenneth Almquist ----------------------------- From: "Vincent C. Hatem" Subject: Re: Autologout of unused terminals Date: 30 Nov 88 15:23:09 GMT To: unix-wizards@sem.brl.mil In article <83@cosmic.sns.UUCP>, holgi@sns.UUCP (Holger Kollmer) writes: # In article <201.nlunix6@orcenl.uucp> bengsig@orcenl.uucp (Bjorn Engsig) writes: # #Is there any way to see if a terminal has not been used for some time, # #and if it hasn't, to send a hangup to the processes there? We are looking # # You can make stat(2) on the tty. That system call returns st_mtime and # st_atime which shows the last access and modification time. You could also use 'who -u' (on Sys V), which tells the idle time... -- Vincent C. Hatem | att ---->\ (available from any AT&T International | ulysses ->\ Action Central site) International Operations Technical Support | bellcore ->\___ !attibr!vch 1200 Mt Kemble Ave, Basking Ridge, NJ 07920 | (201) 953-8030 ----------------------------- From: Clarence Dold Subject: Re: Autologout of unused terminals Date: 29 Nov 88 16:26:40 GMT To: unix-wizards@sem.brl.mil From article <2682@sultra.UUCP>, by dtynan@sultra.UUCP (Der Tynan): > All he wants is the software. Anyway, I don't mind if you spell it out > one more time. I'd like to know why it is better to leave Joe User's > account available for a passer-by, than to kill it. A lot of UN*X sites To back up my system, I do an su, followed by /etc/backup&, then exit. As long as I stay logged in as a normal user, the script continues. If I log out, the script is aborted. I don't leave a terminal in SuperUser lying around, even running a script. -- Clarence A Dold - cdold@starfish.Convergent.COM (408) 434-2083 ...pyramid!ctnews!professo!dold MailStop 18-011 P.O.Box 6685, San Jose, CA 95150-6685 ----------------------------- From: "Richard A. O'Keefe" Subject: Re: fixing rm * (was: Worm/Passwords) Date: 30 Nov 88 11:27:42 GMT Sender: news@quintus.uucp To: unix-wizards@sem.brl.mil In article <1248@atari.UUCP> achar@atari.UUCP (Alan Char) writes: >In article <727@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >|One answer, of course, would be to have a >| GLOBASK=rm:rmdir >|shell variable, so that one could put >| GLOBASK=a.rm:$GLOBASK >|in ones .profile. (Did I just make a constructive suggestion? Oops.) > >GLOBASK is not that different from expandcheck. In fact, >setting GLOBASK= is exactly the same as setting >expandcheck=1 modulo the prompt text. No it isn't, because it is not *possible* to set GLOBASK=. That's an open set. (The set of commands accessible through my $PATH at the moment is 661, and that's after I pruned my $PATH.) It's also quite a different perspective; it's quite pointless to limit echo * | wc -w which expandcheck would do, whereas the GLOBASK approach explicitly identifies only the believed-dangerous commands. I am not seriously proposing GLOBASK; just pointing out that more focussed approaches than expandcheck are possible. ----------------------------- From: Len Reed Subject: Re: Here's a *BRILLIANT* password idea! (Sarcasm on) Date: 30 Nov 88 15:04:31 GMT To: unix-wizards@sem.brl.mil From article <438@amanue.UUCP>, by jr@amanue.UUCP (Jim Rosenberg): = Well now, net folk, since we're talking about good and bad ideas for passwords, = how does this idea strike you. (1) Restrict all passwords to a *MAXIMUM* of = 4 characters. (2) *PROHIBIT* anything but digits from appearing in a password. = = Isn't this nifty? You're probably thinking I'm a nut case. = = Well surprise: This exact password system is ***IN USE***!!! In (are you = ready:) ***BANKS***!!! I am not kidding. Do you have an Automatic Teller = Machine card? What does your password look like? Every time I've been given = one of those things the password was just 4 digits!!!!!!! You have to have physical possession of the card, too, not just knowledge of the account number. The "password" merely stops someone from using the card between the time it is stolen and the theft is reported to and dealt with by the bank. It's a backup to the main security stategy-- possession of the card. Not exactly the same thing as a computer system with dial-in capability. The banks around here have a "three strikes and you're out" rule. If you put the card in and fail three times to get the password right the machine keeps the card. BTW, I do think you're a nut case. -- - Len Reed ----------------------------- From: David Lai Subject: Re: "tip" leaves device file exclusively open Date: 29 Nov 88 22:33:13 GMT Posted: Tue Nov 29 17:33:13 1988 To: unix-wizards@sem.brl.mil In article <318@taux02.UUCP> amos@taux02.UUCP (Amos Shapir) writes: >Check permissions to /usr/spool/uucp. tip creates a lock file there >(usually LCK.something) as user uucp, then does a setuid to the user >that runs it. In some versions, it forgets to setuid back to uucp >before removing the lock, so the remove fails and the lock is left >intact. Sometime the only solution is to make the directory writable >(shudder). >-- > Amos Shapir amos@nsc.com >National Semiconductor (Israel) P.O.B. 3007, Herzlia 46104, Israel >Tel. +972 52 522261 TWX: 33691, fax: +972-52-558322 >34 48 E / 32 10 N (My other cpu is a NS32532) I have a small script I use instead of 'tip' on the sun (which creates the LCK file as uucp but cant remove it afterwards, it is in the path before /usr/bin) tip: #!/bin/sh if test "$1" = "fast"; then a=cuad fi if test "$1" = "slow"; then a=cua0 fi if test "$1" = "slow300"; then a=cua0 fi if test "$1" = "fast" -o "$1" = "slow" -o "$1" = "slow300"; then if /usr/lib/uucp/uuchecklock $a; then /usr/bin/tip $* /usr/lib/uucp/uuunlock $a else echo "modem" $a "busy" fi else /usr/bin/tip $* fi /usr/lib/uucp/uuchecklock: (setuid to uucp) if test -f /usr/spool/uucp/LCK..$1; then exit 1 else exit 0 fi /usr/lib/uucp/uuunlock: (setuid to uucp) #!/bin/sh rm -f /usr/spool/uucp/LCK..$1 -- "What is a DJ if he can't scratch?" - Uncle Jamms Army The views expressed are those of the author, and not of Visual Edge, nor Usenet. David Lai (vedge!lai@larry.mcrcim.mcgill.edu || ...watmath!onfcanim!vedge!lai) ----------------------------- From: Christopher Lott Subject: Re: Autologout of unused terminals Date: 30 Nov 88 21:23:17 GMT Sender: news@tut.cis.ohio-state.edu To: unix-wizards@sem.brl.mil In article <3603@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: >Not only that, but idle-killers are so easy to spoof, unless you disable >people from executing utime() or ioctl(). >Larry Wall >lwall@jpl-devvax.jpl.nasa.gov Well, yes. A friend (Hi, Ed) did so once; was nothing more than writing a little daemon to spit out a newline character using a 4.2BSD ioctl() call every IDLE_TIMEOUT_PERIOD - 1 minutes. But the reason I have put untamo, from Purdue cc, on our largish timeshare machine here was to free up precious hardwire lines to the campus network switch. Allows more people to have access. I maintain that people are slightly flaky at times (me especially) and do forget to log out - so a daemon that cleans up after them is more of a help than a detriment to the sysadmin effort. Putting the daemon to work is not a battle between the stodgy sysadmin and the clever, crafty user but merely another effort to allocate resources more fairly. [ Untamo allows nice exceptions - we never time-out a user on a pty, only on a hardwire line. My xterm client on that machine tends to go idle for long periods, but pseudo terminals are relatively cheap, so it's ok. ] I have no affiliation with untamo and authors except as a user. chris... -=- cml@tut.cis.ohio-state.edu Computer Science Department, OSU 614-292-6546 or: ...!{att,pyramid,killer}!osu-cis!cml ----------------------------- From: Bjorn Engsig Subject: Re: Autologout of unused terminals Date: 30 Nov 88 08:40:00 GMT To: unix-wizards@sem.brl.mil In article <9012@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: > >why it's such a terrible sin to kill these jobs. > > Because any automated scheme you come up is likely to ALSO kill off > some perfectly legitimate jobs. > What I asked for in the first place was just a program to send SIGHUP to processes, which seemed to be doing nothing. There will of course always be cases where this 'seems' is wrong, but a process that wants to live could easily do signal(SIGHUP,handler) (or nohup). When doing this, you show that you are aware of the possible 'auto-killing', and you will be sure not to be killed. This is also a nice thing to do on a modem line. -- Bjorn Engsig, ORACLE Europe \ / "Hofstaedter's Law: It always takes ..!uunet!mcvax!orcenl!bengsig X longer than you expect, even if you phone: +31 21 59 56 411 / \ take into account Hofstaedter's Law" ----------------------------- From: Lars Pensj| Subject: Re: wakeup() race condition. (theory) Date: 29 Nov 88 14:46:40 GMT Keywords: wakeup sleep spl To: unix-wizards@sem.brl.mil In article <1974@van-bc.UUCP> sl@van-bc.UUCP (pri=-10 Stuart Lynne) writes: > x = spl(5); > state |= IAmAsleep; > sleep(...) > splx(x); Just a note about this. It should be x = spl(5); state |= IAmAsleep; ! while (state & IAmAsleep) ! sleep(...); splx(x); because sleep() may wake through other wakeup() with unknown codes. -------------- Lars Pensj| lars@myab.se -- Lars Pensj| lars@myab.se ----------------------------- From: Dan Troxel VP Subject: Afio faster than Cpio??? Date: 30 Nov 88 18:52:48 GMT To: unix-wizards@sem.brl.mil Is it true that afio is faster than cpio? When I run it on a Convergent S/640 (25MHZ 68020), on 5.33 megs, afio takes 45 to 50 seconds longer than cpio. Any suggestions as to what I need to do to get the speed up? The reason I need afio, is that the CT box cpio doesn't handle the magnetic tape to well. (reel-to-reel) -- Dan Troxel VP of Computer Operations @ Handwriting Research Corporation - 2821 E. Camelback Road Suite 600 Phoenix, AZ 85016 WK 1-602-957-8870 HM 1-602-435-1240 UUCP : asuvax!hrc!dan ----------------------------- From: Guy Harris Subject: Re: Ghost file Date: 30 Nov 88 18:57:38 GMT Keywords: ghost, unprintable, unlink To: unix-wizards@sem.brl.mil > char name[] = "badfile?"; > name[7] = (char) 255; Or char name[] = "badfile\377"; which is slightly more convenient. I sincerely *hope* your compiler can cope with that (although it's not inconceivable that the compiler writer dropped the ball).... ----------------------------- From: Paul Muller Subject: Why's and wherefore's..... Date: 30 Nov 88 15:12:49 GMT Keywords: Microport vs. Xenix (for IBM-AT(386) based systems) To: unix-wizards@sem.brl.mil I know this is asking for comp.unix.wizards.flame, but I am rather confused. I have been talking to people in the industry and to collegues over the advantages of SCO Xenix vs Microport Sys V (AT/386), which is better, the last comment I recvd from a friend (who runs Xenix) was that Microport was CRAP! He cited the point that the ttyx drivers are stuffed and that the whole OS is a snail! This is rather odd as a conflicting comment suggested that M/Port runs rings around Xenix on any PC?!?! I would appreciate some expert (read:user) opinion on this as I have to help manage a system that will run a file intensive retrieval system and with around 6 users I need something that can hack the pace and save my bum. I apologise for the contravertialnous (spel?) of the topic, but I really like to know what I'm getting myself into (assuming it makes it through finance Thanks in advance, Paul Muller +61 3 743 5930 (muller@munnari.oz.au) ----------------------------- From: Guy Harris Subject: Re: Mounting floppies Date: 30 Nov 88 19:48:34 GMT To: unix-wizards@sem.brl.mil >BTW: You not only have to look for suid-files, but also for special >device files! Note that "ncheck", both on S5R3 and 4.3BSD, has a "-s" flag to do precisely those checks (it may do so on other UNIX versions as well); I suspect it may do so faster than, say, "find". You may be able to use it, rather than writing your own code to do it.... ----------------------------- From: Amos Shapir Subject: Re: Autologout of unused terminals Date: 30 Nov 88 12:43:25 GMT Hdate: 21 Kislev 5749 To: unix-wizards@sem.brl.mil In article <9012@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) writes: >There are many ways to deal with careless terminal users other than >automatic idle-terminal killer software. Here's one: the following command file, for BSD systems, uses the output of 'w' to mail notes to idle users. The only bug is that such users are usually not there to read their mail... #!/bin/sh w -hs | \ sed -n 's/^\(.........\)\(..\)\(.[0-9]\).*/(echo You have a login session on tty\2\ echo which has been inactive for more than \3 days now. \ echo You can use ps -ut\2 to find out what processes run there and kill them.) \\\ |Mail -s "Idle login session" \1/p' |sh -- Amos Shapir amos@nsc.com National Semiconductor (Israel) P.O.B. 3007, Herzlia 46104, Israel Tel. +972 52 522261 TWX: 33691, fax: +972-52-558322 34 48 E / 32 10 N (My other cpu is a NS32532) ----------------------------- From: "Richard A. O'Keefe" Subject: Re: rm etc. (was: Nasty Security Hole?) Date: 30 Nov 88 14:54:24 GMT Sender: news@quintus.uucp To: unix-wizards@sem.brl.mil In article <13193@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: >As quoted from <730@quintus.UUCP> by ok@quintus.uucp (Richard A. O'Keefe): >| % att rm zabbo >| zabbo: 0 mode ? n >| % bsd rm zabbo >| rm: override protection 0 for zabbo? n >If UUNET is any guide, V.2 on Sequents isn't. > $ >foo ; chmod 0 foo ; rm foo > rm: remove foo? n > >I've seen the above on quite a few systems of V.2, V.3, and Xenix 5.x >persuasions. UNIX System V/386 Release 3.0 80386 says foo: 0 mode ? just like the Sequent. There is more reason to doubt UUNET: the SVID clearly and explicitly states in RM(BU_CMD) that If a file has no write permission and the standard input is a terminal, its [presumably the file's] permissions are printed and a line is read from the standard input. Something which purports to be V.2 "rm" ought to obey the SVID and print the permissions *somehow* (though the SVID doesn't specify a format). Internationalisation will be a great opportunity to tidy this up. ----------------------------- From: "D.Rorke" Subject: Re: wakeup() race condition. (theory) Date: 30 Nov 88 18:47:45 GMT To: unix-wizards@sem.brl.mil > > A few days ago, I posted an article describing a problem > with a driver that didn't return from a sleep(), though > the call to wakeup was performed. > > The process remained in a curious state. It was reported by > ps as runnable (no sleep chan), but the run list pointer > was 0. It also didn't respond to any signal. > > A point to note is that the driver's interrupt routine > priority is 7, and that this routine is calling wakeup() > to awaken the sleeping process. > > Theory: > Sleep & wakeup both call spl6() to ensure secure access to > the process queues, (Well, this is not theory, the calls are > there...) and it is possible for the driver's device to > interrupt as a wakeup() is running, isn't it ? > > As this driver (as SCO xenix serial driver) is running with > prio 7, it's not blocked by spl6() and then it may interfere > with the running wakeup by, say, runnig another wakeup. > > Solution: (?) > Not to call any wakeup at prio 7, that is, put every driver > interrupt routine that calls wakeup at prio 6 or below. > > I would be glad to hear some guru opinion on the topic. Arghh. Most current implementations of wakeup() are not reentrant. I assume yours is not if it's bothering to do an spl6(). Non reentrant wakeup() implementations should set the interrupt level to the highest possible level while executing in a critical section. As you noted, a wakeup() that sets some intermediate interrupt level can be interrupted by an interrupt handler that could potentially call wakeup(). This could cause the problem you observed. It could also panic your system if the sleep queues are implemented as linked lists. The solution you propose above is OK but a better solution (if you have source) is to fix wakeup() to set the highest interrupt level supported by the hardware. Dave Rorke attunix!der > -- > Carlos G. Mendioroz > Work: +54 (1) 313-8082 Fax: +54 (1) 311-1249 > Home: +54 (1) 71-3473 ; Malabia 2659 11 B, Buenos Aires, 1425 ARGENTINA *** REPLACE THIS LINE WITH YOUR MESSAGE *** ----------------------------- From: "D.Rorke" Subject: Re: wakeup() race condition. (theory) Date: 30 Nov 88 19:38:53 GMT To: unix-wizards@sem.brl.mil > > Theory: > > Sleep & wakeup both call spl6() to ensure secure access to > > the process queues, (Well, this is not theory, the calls are > > there...) and it is possible for the driver's device to > > interrupt as a wakeup() is running, isn't it ? > > > > As this driver (as SCO xenix serial driver) is running with > > prio 7, it's not blocked by spl6() and then it may interfere > > with the running wakeup by, say, runnig another wakeup. > > > > Solution: (?) > > Not to call any wakeup at prio 7, that is, put every driver > > interrupt routine that calls wakeup at prio 6 or below. > > > > I would be glad to hear some guru opinion on the topic. > > > Arghh. > > Most current implementations of wakeup() are not reentrant. I assume > yours is not if it's bothering to do an spl6(). Non reentrant > wakeup() implementations should set the interrupt level to the highest > possible level while executing in a critical section. As you noted, > a wakeup() that sets some intermediate interrupt level can be > interrupted by an interrupt handler that could potentially call wakeup(). > This could cause the problem you observed. It could also panic your > system if the sleep queues are implemented as linked lists. > > The solution you propose above is OK but a better solution (if you have > source) is to fix wakeup() to set the highest interrupt level supported > by the hardware. > > > Dave Rorke > attunix!der > > > > -- > > Carlos G. Mendioroz > > Work: +54 (1) 313-8082 Fax: +54 (1) 311-1249 > > Home: +54 (1) 71-3473 ; Malabia 2659 11 B, Buenos Aires, 1425 ARGENTINA > A clarification of my response above. I said that the solution that Carlos proposed was OK. It is not however, sufficient to simply set the interrupt priority level low before calling wakeup in the interrupt routine, if the device interrupts at a level greater than the level set in wakeup(). For example, in the case he cites above you couldn't just set the interrupt level down to 6 at the beginning of the serial driver interrupt routine if the hardware interrupt actually comes in at level 7. This won't solve the problem and can create additional problems because the interrupt routine itself may not be reentrant, and setting the level of the interrupt routine lower than the level of the corresponding hardware interrupt could cause the interrupt routine to be re-entered. What you can do (assuming you can't fix wakeup) is make sure you don't have any devices configured on your system which: a) interrupt at a level greater than the level set in wakeup() and b) invoke interrupt handlers that call wakeup() Of course similar problems can exist with any kernel function that manipulates global data without blocking all interrupts that could result in interrupt handlers manipulating the same global data. Dave Rorke attunix!der ----------------------------- From: Leslie Mikesell Subject: Re: ioctl in perl (was: using System V 'cu') Date: 30 Nov 88 16:53:25 GMT To: unix-wizards@sem.brl.mil In article <3605@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: >: How about adding ioctl() to perl so we can use it instead? >Er, um, that's kinda hard. But I been thinkin' about it. I was just thinking in terms of being able to dial out a tty port and chat and/or exec some file transfer protocol (with uucp compatible lock files, etc.) For that purpose it might be easier to build in "stty" instead of the full ioctl() functionality with the associated problem of undefined structs. However, perhaps I should ask your opinion on a "higher-level" approach. What would you do if you did not have "rsh" and needed similar functionality over dial-up or direct serial lines with some unix, some non-unix machines. I'm using various versions of kermit for some of this, especially exchanging files with a VM/CMS host where nothing else works, but I'm not entirely satisfied with it. Should I be looking at SLIP and something to emulate rsh under SysV, or a wrapper around zmodem protocol (this may need to run over a satellite connection), or fixing kermit to do what I want, or...? Les Mikesell ----------------------------- From: "Brandon S. Allbery" Subject: Re: Predictable Date: 1 Dec 88 00:15:35 GMT Followup-To: comp.unix.wizards To: unix-wizards@sem.brl.mil As quoted from <4271@encore.UUCP> by bzs@encore.com (Barry Shein): +--------------- | From: allbery@ncoast.UUCP (Brandon S. Allbery) | >...But the network entry point to sendmail is | >via a particular Internet port; while a random user cannot alter the shell | >for another user in /etc/password and cannot replace /usr/lib/uucp/uucico | >with another program (or so we hope), if the SMTP port weren't root-only | >*any* user could arrange for their own program to listen on the SMTP port | >and wreak all kinds of havoc on other systems. Or at minimum could read | >anyone's incoming net mail. Fun, eh? | | In the first place that's one big *IF* (*IF* the SMTP port weren't | root-only...) If a user can bypass root security on the system why is | your main concern that they might intercept someone's incoming mail? | Of course they can, they can just 'cat /usr/spool/mail/yournamehere' | and delete what they want etc, why bother with the SMTP port? +--------------- The question was why the SMTP port *was* root-only. +--------------- | And what kind of havoc exactly can someone wreak on other systems by | listening for incoming mail connections? I mean something peculiar to | this ability and, what the hell, something they can't do otherwise via | root permissions since that's a pre-requisite. +--------------- Sorry. Dumb mistake. It didn't occur to me until a few days ago, in conjunction with a *different* network protocol, that there was no reason for SMTP commands to be bidirectional. (I.e. the fact that you can transmit SMTP *commands* to a program listening on port 25 doesn't mean that the receiving program can then transmit another SMTP command [e.g. DEBUG] *back*.) ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu allberyb@skybridge.sdi.cwru.edu allbery@uunet.uu.net comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@. ----------------------------- From: "Brandon S. Allbery" Subject: Re: what is the 'l' permission? Date: 1 Dec 88 00:22:29 GMT Followup-To: comp.unix.questions To: unix-wizards@sem.brl.mil As quoted from <951@vsi.COM> by friedl@vsi.COM (Stephen J. Friedl): +--------------- > (re: the "l" mode bit in SVR3.2 and mandatory/advisory file locking) | | I'm speculating on this part, but I guess that setting the `l' mode | is required because the vast majority of programs don't use locking, | and the overhead required on each read/write call is probably too much. | Setting the lock bit probably enables this checking. +--------------- No, it's because advisory file locking is the SVR3 standard, but mandatory file locking was in Xenix. So UNIX apps use standard file locking and migrated Xenix apps should set the "l" bit in order to work correctly. I dunno, the whole thing seems a bit klugey to me. ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu allberyb@skybridge.sdi.cwru.edu allbery@uunet.uu.net comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@. ----------------------------- From: Dan Schlitt Subject: Re: Re: The Internet Virus--Another issue Date: 30 Nov 88 15:02:51 GMT Posted: Wed Nov 30 10:02:51 1988 To: unix-wizards@sem.brl.mil In article <4470010@hpindda.HP.COM> marcel@hpindda.HP.COM (Marcel Burlet) writes: :/ kai@uicsrd.csrd.uiuc.edu / 8:44 pm Nov 17, 1988 / :>(Some) other manufacturers are doing something about it. :>Sequent mailed a shell script to patch sendmail to disable debug. :>Alliant did one better. They have debug disabled in the sendmail they :>distribute. : :HP also has debug disabled in the distribution. (Guess when I found this :out. Right, *after* getting the scare of my life !) : I'm still waiting for Celerity's new parent to do something. But there is really more to this than sendmail debug. After a bit of fussing I got adb to fix sendmail on the Celerity. I haven't seen a method for using adb to fix fingerd and ftpd. They need fixing too. Before patting too many vendors on the back for fixing things (or distributing safe versions) let's see them fix the harder problems. -- Dan Schlitt Manager, Science Division Computer Facility dan@ccnysci City College of New York dan@ccnysci.bitnet New York, NY 10031 (212)690-6868 ----------------------------- End of UNIX-WIZARDS Digest **************************