Mail not delivered yet, still trying
SMTP MAILER
postmaster at nusc.arpa
Fri Dec 2 05:29:32 AEST 1988
----Mail status follows----
Have been unable to send your mail to <baynes at drum>,
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: <unix-wizards at BRL.MIL>
Subject: UNIX-WIZARDS Digest V6#035
To: "baynes" <baynes at drum>
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) <Unix-Wizards-Request at BRL.MIL>
To: UNIX-WIZARDS at BRL.MIL
Reply-To: UNIX-WIZARDS at BRL.MIL
Subject: UNIX-WIZARDS Digest V6#035
Message-ID: <8812010245.aa04864 at 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 <lm at snafu.sun.com>
Subject: Re: random passwords (was Re: Worm...)
Date: 30 Nov 88 02:22:04 GMT
Sender: news at sun.uucp
To: unix-wizards at 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 at sun.com)
-----------------------------
From: Stefan Stapelberg <stefan at mikros.systemware.de>
Subject: Re: Mounting floppies
Date: 29 Nov 88 10:10:52 GMT
To: unix-wizards at sem.brl.mil
In article <5682 at louie.udel.EDU> law at 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 <stefan at mikros.uucp> Phone: +49 9352 5948
-----------------------------
From: DAVID NEWALL <ccdn at levels.sait.edu.au>
Subject: Re: Ghost file
Date: 25 Nov 88 12:11:13 GMT
Keywords: ghost, unprintable, unlink
To: unix-wizards at 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 at levels.sait.oz.au
SA Institute of Technology Post: The Levels, South Australia, 5095
-----------------------------
From: storm development account <storm at reign.uucp>
Subject: Need news feed (pref. in DC area)
Date: 30 Nov 88 03:36:01 GMT
Keywords: dc news feed
To: unix-wizards at 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 <bengsig at orcenl.uucp>
Subject: Re: Autologout of unused terminals
Date: 29 Nov 88 15:48:19 GMT
To: unix-wizards at sem.brl.mil
In article <201.nlunix6 at 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 <lwall at jpl-devvax.jpl.nasa.gov>
Subject: ioctl in perl (was: using System V 'cu')
Date: 30 Nov 88 06:51:33 GMT
To: unix-wizards at 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 at jpl-devvax.jpl.nasa.gov
"So many programs, so little time..."
-----------------------------
From: Henry Spencer <henry at utzoo.uucp>
Subject: Re: what is the 'l' permission?
Date: 29 Nov 88 19:31:57 GMT
To: unix-wizards at sem.brl.mil
In article <516 at auspex.UUCP> guy at 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 at zoo.toronto.edu
-----------------------------
From: Henry Spencer <henry at utzoo.uucp>
Subject: Re: cat -u
Date: 29 Nov 88 19:41:10 GMT
To: unix-wizards at sem.brl.mil
Organization: U of Toronto Zoology
Lines: 9
In article <4864 at bsu-cs.UUCP> dhesi at 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 at zoo.toronto.edu
-----------------------------
From: Clay M Bond <bondc at iuvax.cs.indiana.edu>
Subject: Re: umlaut
Date: 30 Nov 88 11:24:03 GMT
To: unix-wizards at 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 at iuvax.cs.indiana.edu AKA: Le Nouveau Marquis de Sade >>
<< {pur-ee,rutgers,pyramid,ames}!iuvax!bondc *********************** >>
-----------------------------
From: Chris Torek <chris at mimsy.uucp>
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 at 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 at cps3xx.UUCP> rang at 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 at tekcrl.CRL.TEK.COM> terryl at 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 at mimsy.umd.edu Path: uunet!mimsy!chris
-----------------------------
From: Mike Klaus <mak at ndc.uucp>
Subject: Re: The Internet Virus--Another issue
Date: 29 Nov 88 17:28:55 GMT
To: unix-wizards at 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 <chris at mimsy.uucp>
Subject: Re: 4.3 BSD networking bugs
Date: 30 Nov 88 13:18:09 GMT
To: unix-wizards at sem.brl.mil
In article <204 at hsi86.hsi.UUCP> stevens at 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 at mimsy.umd.edu Path: uunet!mimsy!chris
-----------------------------
From: "Snoopy T. Beagle" <snoopy at sopwith.uucp>
Subject: Software Quality (was: Re: rtm and uucp)
Date: 29 Nov 88 23:48:09 GMT
Followup-To: comp.software-eng
To: unix-wizards at sem.brl.mil
In article <1988Nov15.180821.20324 at utzoo.uucp> henry at 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 <jbrown at herron.uucp>
Subject: Re: Worm/Passwords
Date: 30 Nov 88 12:56:14 GMT
To: unix-wizards at sem.brl.mil
jbayer at ispi.UUCP (Jonathan Bayer) writes...
> In article <10 at herron.uucp>, jbrown at herron.uucp (Jordan Brown) writes:
> > jbayer at 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 <ka at june.cs.washington.edu>
Subject: Echo
Date: 30 Nov 88 14:18:11 GMT
To: unix-wizards at 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" <vch at attibr.uucp>
Subject: Re: Autologout of unused terminals
Date: 30 Nov 88 15:23:09 GMT
To: unix-wizards at sem.brl.mil
In article <83 at cosmic.sns.UUCP>, holgi at sns.UUCP (Holger Kollmer) writes:
# In article <201.nlunix6 at orcenl.uucp> bengsig at 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 <cdold at starfish.convergent.com>
Subject: Re: Autologout of unused terminals
Date: 29 Nov 88 16:26:40 GMT
To: unix-wizards at sem.brl.mil
>From article <2682 at sultra.UUCP>, by dtynan at 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 at 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" <ok at quintus.uucp>
Subject: Re: fixing rm * (was: Worm/Passwords)
Date: 30 Nov 88 11:27:42 GMT
Sender: news at quintus.uucp
To: unix-wizards at sem.brl.mil
In article <1248 at atari.UUCP> achar at atari.UUCP (Alan Char) writes:
>In article <727 at quintus.UUCP> ok at 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=<all commands> is exactly the same as setting
>expandcheck=1 modulo the prompt text.
No it isn't, because it is not *possible* to set GLOBASK=<all commands>.
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 <lbr at holos0.uucp>
Subject: Re: Here's a *BRILLIANT* password idea! (Sarcasm on)
Date: 30 Nov 88 15:04:31 GMT
To: unix-wizards at sem.brl.mil
>From article <438 at amanue.UUCP>, by jr at 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 <lai at vedge.uucp>
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 at sem.brl.mil
In article <318 at taux02.UUCP> amos at 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 at 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 at larry.mcrcim.mcgill.edu || ...watmath!onfcanim!vedge!lai)
-----------------------------
From: Christopher Lott <cml at brachiosaur.cis.ohio-state.edu>
Subject: Re: Autologout of unused terminals
Date: 30 Nov 88 21:23:17 GMT
Sender: news at tut.cis.ohio-state.edu
To: unix-wizards at sem.brl.mil
In article <3603 at jpl-devvax.JPL.NASA.GOV> lwall at 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 at 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 at tut.cis.ohio-state.edu Computer Science Department, OSU 614-292-6546
or: ...!{att,pyramid,killer}!osu-cis!cml <standard disclaimers>
-----------------------------
From: Bjorn Engsig <bengsig at orcenl.uucp>
Subject: Re: Autologout of unused terminals
Date: 30 Nov 88 08:40:00 GMT
To: unix-wizards at sem.brl.mil
In article <9012 at smoke.BRL.MIL>, gwyn at 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| <lars at myab.se>
Subject: Re: wakeup() race condition. (theory)
Date: 29 Nov 88 14:46:40 GMT
Keywords: wakeup sleep spl
To: unix-wizards at sem.brl.mil
In article <1974 at van-bc.UUCP> sl at 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 at myab.se
--
Lars Pensj|
lars at myab.se
-----------------------------
From: Dan Troxel VP <dan at hrc.uucp>
Subject: Afio faster than Cpio???
Date: 30 Nov 88 18:52:48 GMT
To: unix-wizards at 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 <guy at auspex.uucp>
Subject: Re: Ghost file
Date: 30 Nov 88 18:57:38 GMT
Keywords: ghost, unprintable, unlink
To: unix-wizards at 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 <muller at munnari.oz>
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 at 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 at munnari.oz.au)
-----------------------------
From: Guy Harris <guy at auspex.uucp>
Subject: Re: Mounting floppies
Date: 30 Nov 88 19:48:34 GMT
To: unix-wizards at 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 <amos at taux02.uucp>
Subject: Re: Autologout of unused terminals
Date: 30 Nov 88 12:43:25 GMT
Hdate: 21 Kislev 5749
To: unix-wizards at sem.brl.mil
In article <9012 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) 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 at 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" <ok at quintus.uucp>
Subject: Re: rm etc. (was: Nasty Security Hole?)
Date: 30 Nov 88 14:54:24 GMT
Sender: news at quintus.uucp
To: unix-wizards at sem.brl.mil
In article <13193 at ncoast.UUCP> allbery at ncoast.UUCP (Brandon S. Allbery) writes:
>As quoted from <730 at quintus.UUCP> by ok at 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" <der at sfmag.uucp>
Subject: Re: wakeup() race condition. (theory)
Date: 30 Nov 88 18:47:45 GMT
To: unix-wizards at 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 <tron at mrecvax.mrec.ar>
> 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" <der at sfmag.uucp>
Subject: Re: wakeup() race condition. (theory)
Date: 30 Nov 88 19:38:53 GMT
To: unix-wizards at 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 <tron at mrecvax.mrec.ar>
> > 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 <les at chinet.chi.il.us>
Subject: Re: ioctl in perl (was: using System V 'cu')
Date: 30 Nov 88 16:53:25 GMT
To: unix-wizards at sem.brl.mil
In article <3605 at jpl-devvax.JPL.NASA.GOV> lwall at 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" <allbery at ncoast.uucp>
Subject: Re: Predictable
Date: 1 Dec 88 00:15:35 GMT
Followup-To: comp.unix.wizards
To: unix-wizards at sem.brl.mil
As quoted from <4271 at encore.UUCP> by bzs at encore.com (Barry Shein):
+---------------
| From: allbery at 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 <PREFERRED!> ncoast!allbery at hal.cwru.edu
allberyb at skybridge.sdi.cwru.edu <ALSO> allbery at 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@<backbone>.
-----------------------------
From: "Brandon S. Allbery" <allbery at ncoast.uucp>
Subject: Re: what is the 'l' permission?
Date: 1 Dec 88 00:22:29 GMT
Followup-To: comp.unix.questions
To: unix-wizards at sem.brl.mil
As quoted from <951 at vsi.COM> by friedl at 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 <PREFERRED!> ncoast!allbery at hal.cwru.edu
allberyb at skybridge.sdi.cwru.edu <ALSO> allbery at 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@<backbone>.
-----------------------------
From: Dan Schlitt <dan at ccnysci.uucp>
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 at sem.brl.mil
In article <4470010 at hpindda.HP.COM> marcel at hpindda.HP.COM (Marcel Burlet) writes:
:/ kai at 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 at ccnysci City College of New York
dan at ccnysci.bitnet New York, NY 10031
(212)690-6868
-----------------------------
End of UNIX-WIZARDS Digest
**************************
More information about the Comp.unix.wizards
mailing list