UNIX-WIZARDS Digest V5#105
Mike Muuss
Unix-Wizards-Request at arpa.brl
Sat Jul 23 17:45:17 AEST 1988
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 at watdcsu.waterloo.edu>
Subject: Re: Who dat?
Date: 22 Jul 88 03:09:48 GMT
To: unix-wizards at brl-sem.arpa
In article <14931 at oddjob.UChicago.EDU> matt at oddjob.UChicago.EDU (Ka Kahula) writes:
>) In article <3789 at rpp386.UUCP>, jfh at rpp386.UUCP (John F. Haugh II) writes:
>) > have the client create a file with the suid and sgid bits set. ...
>
>In article <51 at minya.UUCP> jc at 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 at 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 at brl-sem.arpa
In article <531 at prlhp1.prl.philips.co.uk> ockenden at 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 at 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 at seismo.css.gov>
Subject: Request for user-contributed software
Date: 22 Jul 88 16:50:36 GMT
Keywords: 4BSD, user-contributed
To: unix-wizards at 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 at okeeffe.berkeley.edu
-----------------------------
From: "Brandon S. Allbery" <allbery at ncoast.uucp>
Subject: Re: Input Line Editing
Date: 22 Jul 88 23:18:33 GMT
Followup-To: comp.unix.wizards
To: unix-wizards at brl-sem.arpa
As quoted from <9666 at eddie.MIT.EDU> by nessus at wonko.MIT.EDU (Doug Alan):
+---------------
| In article <16456 at brl-adm.ARPA> rbj at 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 at esunix.uucp>
Subject: Re: Input Line Editing
Date: 21 Jul 88 15:02:27 GMT
To: unix-wizards at SEM.BRL.MIL
>From article <1112 at ficc.UUCP>, by peter at ficc.UUCP (Peter da Silva):
> In article <9677 at eddie.MIT.EDU>, nessus at 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
**************************
More information about the Comp.unix.wizards
mailing list