Unix-Wizards-Request@arpa.brl (Mike Muuss) (07/23/88)
UNIX-WIZARDS Digest Sat, 23 Jul 1988 V5#105 Today's Topics: Re: Who dat? Re: Cheaper winnies on an NCR tower Request for user-contributed software Re: Input Line Editing ----------------------------------------------------------------- From: David Canzi <dmcanzi@watdcsu.waterloo.edu> Subject: Re: Who dat? Date: 22 Jul 88 03:09:48 GMT To: unix-wizards@brl-sem.arpa In article <14931@oddjob.UChicago.EDU> matt@oddjob.UChicago.EDU (Ka Kahula) writes: >) In article <3789@rpp386.UUCP>, jfh@rpp386.UUCP (John F. Haugh II) writes: >) > have the client create a file with the suid and sgid bits set. ... > >In article <51@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >) Let's see, what I do when you ask my process A to create this file is >) to have a program B sitting around that is setuid/setgid to whomever >) I want you to think A is; ... > >If you have this program B, you can impersonate your victim completely. >Why not just assume that you have your victim's password? It comes >to the same thing. In versions of UNIX with which I am familiar, you need no permissions of any kind on a file to make new links to it. So if there are setuid files owned by root on the same filesystem as the directory where the client process is supposed to create the setuid file, then any random user can impersonate Mr. Root. Maybe a server can securely verify the userid of a client by requiring the client to create a setuid file with name *and* *contents* specified by the server? -- I am not David Canzi, my name is. ----------------------------- From: Sam Vause <vause@cs-col.columbia.ncr.com> Subject: Re: Cheaper winnies on an NCR tower Date: 22 Jul 88 12:13:48 GMT Keywords: NCR TOWER 32/600 drive To: unix-wizards@brl-sem.arpa In article <531@prlhp1.prl.philips.co.uk> ockenden@prlhp1.prl.philips.co.uk (Paul T Ockenden) writes for someone else : :NCR Drives : A Plea for help. : :We have an NCR Tower 32/600 here. NCR being the *wonderful* :people they are want about (UK#)4500 for a 140Mb drive. This sticks in :my throat. : :First. Without going to an external cabinet, is there anyway of getting :a bigger than 140Mb drive *INSIDE* the 32/600. We already have one 140Mb Yes. You would have to purchase the 650 upgrade kit which would give you an internal SCSI controller, and the ability to add 170MB disks. :and the 46Mb drive so we could say bye bye to the 46Mb, if we could boot :on it.... or move the 140Mb into the 46Mb's place... All suggestions :gratefully accepted..... : :Second. 4500 UK Pnds for a 140Mb drive is er... a little steep... No kidding! That's about US$7,425 at the moment, primarily due to the VAT and other taxes in the UK, plus the sheer conversion rate difference (some- thing like US$1.65 = UK#1.00 at the moment...) :Does :anyone know how to install a non-NCR drive into a 32/600 without :waking up at night cold and sweating. The design of the operating System disk interface code precludes the addition of any non-approved disk into the TOWER. The reason for this is *NOT* to inconvenience you as a customer, but to make sure that only *CERTIFIED* drives are installed--the reliability of the machine and its data is the most impor- tant issue here. Drives this size *MUST* have an extremely high reliability rating. HOWEVER, having said this, I have seen Maxtor XT1140 drives for sale as low as US$1595 in various "Computer Shopper" magazines. NCR cannot be responsible for the performance and reliability of drives purchased through a third-party vendor. :PS. These drives would have to take a hammering..... Don't they all--that's one of the advantages of purchasing one from us--we've completed as much stress testing and evaluation as humanly possible. Such testing guarantees that the drives you purchase from us will be as reliable as one could hope for. Period. :Thanks in advance : : DJ. :Paul Ockenden Philips Radiotheapy Systems, Crawley, UK +44 293 28787 x 4349 : UUCP - uunet!mcvax!ukc!prlhp1!ockenden JANET - ockenden%prlhp1@uk.ac.Ukc : Opions (where expressed), are those of Paul Ockenden the individual, NOT : Paul Ockenden the Philips Employee !! You're welcome! +------------------------------------------------------------------+ |Sam Vause, NCR Corporation, Customer Services - TOWER Support | |3325 Platt Springs Road, West Columbia, SC 29169 (803) 791-6953 | | ...!ucbvax!sdcsvax!ncr-sd!ncrcae!cs-col!vause | +------------------------------------------------------------------+ ----------------------------- From: Keith Bostic <keith@seismo.css.gov> Subject: Request for user-contributed software Date: 22 Jul 88 16:50:36 GMT Keywords: 4BSD, user-contributed To: unix-wizards@SEM.BRL.MIL BSD will be starting a new cycle of software development this summer. As most of you know, much of the software made available through Berkeley was contributed by the user community. We wish to continue this tradition and encourage anyone who is interested in contributing software to the user community to contact us. We also have many projects, ranging in difficulty from weekend hacks to master's or doctorate level work, that we do not have time to do ourselves. Possible projects include: autodialer manager/daemon biff(1) replacement (mail notification) conferencing system csh cleanups and the addition of ksh features, particularly functions and command line editing System V compatible cron(8) and at(1) programs documentation browsing system multi-buffered tape driver multiuser, message-based application scheduler public-domain NFS replacement of current various current utilities with public domain source code make(1) replacement We would appreciate being contacted by anyone interested working on these, or any other, projects. Keith Bostic 415-642-4948 uunet!keith bostic@okeeffe.berkeley.edu ----------------------------- From: "Brandon S. Allbery" <allbery@ncoast.uucp> Subject: Re: Input Line Editing Date: 22 Jul 88 23:18:33 GMT Followup-To: comp.unix.wizards To: unix-wizards@brl-sem.arpa As quoted from <9666@eddie.MIT.EDU> by nessus@wonko.MIT.EDU (Doug Alan): +--------------- | In article <16456@brl-adm.ARPA> rbj@nav.icst.nbs.gov (Root Boy Jim) writes: | > I suspect that the real place for line editing is either in the shell | > itsef (as in tcsh, ksh, (and brlsh?)) or in the kernel. | | Putting line editing in the shell is wrong, because it should work in | all programs and be consistent. Putting it in the kernal is gross. | Thus, the right place to put it is precisely where Bob Pendleton wants | to put it -- in a process which gets input from the user and feeds | edited input to the user's other programs. If needed, mods to the | kernal and convention, however, should be made to make this as easy | and efficient as possible. +--------------- ??? Why not just a modified version of gets()? If you're running under SVR3, you can build a new version of the shlib with the new gets() and thereby upgrade every program on the system without recompiling! (NOTE: [1] Using scanf() to do terminal input provides insufficient protection from erroneous input and insufficient user-friendliness; using a loop of getchar()'s is a bit weird. I always use gets(), so all my programs would work first time. Other programs? Dunno, depends on how crazy the programmers were. [2] It would, of course, distinguish between a terminal and a non-terminal (heck, stdio does this now), so gets() used in a filter wouldn't fry sort's (for example) little mind.) I may actually try this, after backing up my system: if it goes wrong I can boot from the floppy and full-restore. . . . ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc ----------------------------- From: Bob Pendleton <bpendlet@esunix.uucp> Subject: Re: Input Line Editing Date: 21 Jul 88 15:02:27 GMT To: unix-wizards@SEM.BRL.MIL From article <1112@ficc.UUCP>, by peter@ficc.UUCP (Peter da Silva): > In article <9677@eddie.MIT.EDU>, nessus@wonko.MIT.EDU (Doug Alan) writes: >> There is another way to guarantee that line editing will be uniformly >> supported. (1) Provide an alternate, and better method. (See my and >> some other's previous articles on the issue). (2) Remove line editing >> completely from the kernal, forcing everyone to use the better method. > > ... Six context switches, at the minimum. > Plus you execute in user mode. if your program requires swapping or paging > to wake up, it's even worse. > > Not only that, but all your programs now have to check to see if they're > in a pipeline and turn this stuff off when they are. > > this isn't that much compared to what you Athena jockeys already do, but > it'll kill us poor folks with "mere" vax-class machines and terminals, shared > among a dozen users. Interactive response time will go to hell. > -- > Peter da Silva What Peter says is true. BUT, it is not a reason to stop looking for better ways to do things, or for opposing changes that would make using separate input line editing processes easier. The way things change in this business, by the time all the details are worked out the performance/price ratio will have increased by another factor of 2. Some people will still be stuck on ancient, oeverloaded systems, bot most won't. I use ile every day on a Sun 3/50 and an ULTRIX VAX-750. Sometimes its too slow on the 750. I don't notice it on a the Sun. Bob P. -- Bob Pendleton @ Evans & Sutherland UUCP Address: {decvax,ucbvax,allegra}!decwrl!esunix!bpendlet Alternate: utah-cs!esunix!bpendlet I am solely responsible for what I say. ----------------------------- End of UNIX-WIZARDS Digest **************************