|
|
| Author |
Message |
| 25 new of 187 responses total. |
mary
|
|
response 75 of 187:
| 
May 14 19:38 UTC 1997 |
I agree with you Valerie in that those who are tenacious and
can afford to wait for a login prompt won't be penalized
by the queue. And it is much fairer for the majority of
telnet users.
|
arianna
|
|
response 76 of 187:
|
May 15 00:28 UTC 1997 |
Something weird happened to me tonight whe I logged in: the login prompt came
up, I typed in my login, then the password prompt, and I typed in my password
-- but just after the MOTD and my little "you have new mail" message came up,
the login prompt came up *again*, so I logged in again. I kind of expected
to be logged in twice, but I wasn't... Hm.
|
senna
|
|
response 77 of 187:
|
May 15 02:40 UTC 1997 |
By far. Remember, you can call up a list of who is waiting, but they wont'
be logged in yet so all you'll get is IP addresses. I remember the first time
I discovered the queue and the line was some 200 people long.. or that's the
numger I got. I assumed it was a mistake.
For the ambitious multitasker, the telnet queue not only saves you trouble
of multiple telnets, but it allows you to run netscape or other internet
programs while you're waiting.
|
mcnally
|
|
response 78 of 187:
|
May 15 05:25 UTC 1997 |
re #76: that happened to me recently, too..
|
mdw
|
|
response 79 of 187:
|
May 15 09:17 UTC 1997 |
Re #76 - problems right after the "you have new mail" message are
generally due to problems starting up the shell. In this case, arianna
has a 200K core file from tcsh, which seems to have died early on from a
segmentation fault. That definitely means a bug in tcsh. Strangely
enough, mcnally has the same shell.
|
dpc
|
|
response 80 of 187:
|
May 15 14:57 UTC 1997 |
The load average is *over 20* right now and the system is s-l-o-w.
Any idea why?
|
valerie
|
|
response 81 of 187:
|
May 15 15:39 UTC 1997 |
This response has been erased.
|
arianna
|
|
response 82 of 187:
|
May 15 16:43 UTC 1997 |
Hm... maybe this would correlate with my other problem with my shell -- Even
tho' I've changed my .login to specify that my kill key is ^X, it still thinks
that it's ^U, and it also thinks that ^X is my reprint key..... It's a very
confoozeledf shell..
|
dang
|
|
response 83 of 187:
|
May 15 20:45 UTC 1997 |
I've never had any trouble with tcsh... Can we get a new version of it? I'll
take a look.
|
scg
|
|
response 84 of 187:
|
May 16 03:19 UTC 1997 |
I had the problem arianna describes once a few months ago, I think. I also
use tcsh.
|
senna
|
|
response 85 of 187:
|
May 16 20:00 UTC 1997 |
Why is it that every time I leave pine, I get another You Have New Mail
message shortly afterward, regardless of whether or not its true?
|
mcnally
|
|
response 86 of 187:
|
May 16 20:22 UTC 1997 |
My guess is that your shell (or comsat, or biff, or whatever it is that's
reporting your new mail..) is merely checking the modification date on
the mail spool file to see if it's been changed and deducing new mail from
that. Since pine modifies that file and writes it when it exits, maybe
that's what's happening?
(Although that'd be a stupid way to check for new mail.. The "right"
way is to check the "Status:" headers on the messages to see if they've
been read or not..)
|
tsty
|
|
response 87 of 187:
|
May 17 03:59 UTC 1997 |
possilby senna, your replies and/or newly sent email included
either yourself as a recipient directly or as a cc:
that would deliver newmail to your spool *after* you had opened pine.
|
kaplan
|
|
response 88 of 187:
|
May 17 12:15 UTC 1997 |
User ariel0 wrote me to ask a aboutlosing her connection to grex:
as i get booted it gets locked up then suddenly it says connection closed by
foreign host non socket to socket operation occured
Anyone know what a non socket to socket operation is?
|
i
|
|
response 89 of 187:
|
May 17 15:02 UTC 1997 |
The shell crash & re-login problem would make me nervous about faked login
programs (password snachers, whatever). How secure is grex against that
sort of mischief?
|
dang
|
|
response 90 of 187:
|
May 17 18:00 UTC 1997 |
It would require root to change the login program. So, Grex is as secure
against that as it is against root breakin. If someone had root, they could
just change anyone's password anyway, so changing login is not the most
destructive thing they could do. (However, it tcsh is seg faulting, then it's
unlikely that it's a login snooper.)
|
scg
|
|
response 91 of 187:
|
May 17 19:59 UTC 1997 |
The goal of having people type their passwords into such a program, rather
than just changing passwords, would presumably be that people tend to use the
same password in more than one place, so that might help break into other
systems. That's why it's a bad idea to use the same password in multiple
places.
As others have said, though, if tcsh is seg faulting, it doesn't sound
like somebody breaking in.
|
i
|
|
response 92 of 187:
|
May 18 14:20 UTC 1997 |
Maybe I didn't make it clear, maybe I'm way out of date. The scheme I'm
thinking of starts with some wanna-be cracker named, say Adolf. Adolf
writes (or downloads, or whatever) a little program that clears the
terminal screen, then writes to it the same strings that the real login
program would ("Welcome to Grex .... grex.cyberspace.org login:"). Some
other user named, say Victim, come along to use the terminal. Victim
naturally assumes that he's seeing the login screen, enters his user name
and password, and Adolf's program stores both for future use. Adolf's
program typically would try to die in an unsuspicious way at that point
(complain of wrong password & hope Victim assumes that it was his own
typing error, fake a shell crash, whatever) and let the real login program
come up on the terminal. Victim then logs in normally, and probably
suspects nothing.
With dial-in lines instead of physical access terminals, Adolf's program
has a tougher time of it - it has to make it through the security bottleneck
surrounding hanging up the modem and waiting for an incoming call. But
opportunity also increases greatly - modem problems and line noise are
good, unsuspicious ways to die, and there's a much better chance that the
Victim dialing in will be root.
Adolf does not need root access to launch this type of attack on a UNIX
system that isn't carefully designed to prevent this type of attack. Adolf
may have no ambition higher than cracking Grex (bad enough from our point of
view!). I agree that tcsh crashing does not represent this type of attack -
it merely brought it to mind.
|
mcnally
|
|
response 93 of 187:
|
May 18 18:42 UTC 1997 |
Actually "Adolf" does need either root priveleges or a substantial
misconfiguration by those who have said priveleges to get his program
run by getty when a dial-up user first connects..
|
arianna
|
|
response 94 of 187:
|
May 18 19:41 UTC 1997 |
eep!
|
dang
|
|
response 95 of 187:
|
May 18 20:10 UTC 1997 |
And in the case of Grex, Adolf needs root privilages in order to set up his
little snooper.
|
valerie
|
|
response 96 of 187:
|
May 19 03:00 UTC 1997 |
This response has been erased.
|
senna
|
|
response 97 of 187:
|
May 19 05:01 UTC 1997 |
If an unauthorized person has root, we're in deep you-know-what.
|
arabella
|
|
response 98 of 187:
|
May 20 09:41 UTC 1997 |
How is it possible that I'm the only one logged in right now?
Wow.
|
creole
|
|
response 99 of 187:
|
May 20 11:49 UTC 1997 |
Is that a system problem?
|
