Date: Thu, 11 May 2000 12:55:40 -0400 From: Mike Tancsa <mike@sentex.ca> To: questions@FreeBSD.ORG Cc: security@FreeBSD.ORG Subject: Re: Cant su Message-ID: <3.0.5.32.20000511125540.019f1ea0@marble.sentex.ca> In-Reply-To: <Pine.BSF.4.21.0005102118120.90428-100000@ren.sasknow.com> References: <4.2.2.20000510202431.03935c20@mail.sentex.net>
next in thread | previous in thread | raw e-mail | index | archive | help
At 09:30 PM 5/10/00 -0600, Ryan Thompson wrote:
>Mike Tancsa wrote to questions@FreeBSD.ORG:
>
>>
>> I have a test box that is having problems with su. If I do something like
>> su username
>>
>> and give it the wrong password, it just hangs
>>
>> buildbox% su mdtancsa
>> Password:
>> Sorry
>>
>>
>> And it just hangs after the sorry. Any ideas what might be going on ?
>>
>> 3.4-STABLE FreeBSD 3.4-STABLE #0: Mon Mar 6 20:10:37 EST 2000
>>
>> ---Mike
>
>I don't see this behaviour on either of my 3.4 machines (one machine was
>updated last week. The other is running from a 2 m.o. cvsup), using
>descrypt on one.
>
>Define "hangs"... I.e., if this is on a local vty, can you switch to
>another? I assume ^C/^Z don't knock it out? Does it hang the whole box
>(can you ping/login to the machine?). Or is su the only process that's
>hanging? Can you do a ps -axl? Is the box using remote passwords?
>
>Have you changed your crypt libs around lately? Are all the links as they
>should be? Modtimes sufficiently old?
>
>Occasionally, on virtual terminals, when a program exits on failure
>(usually after it dumps core), I don't get a prompt back, and the term
>wreaks havoc with the keyboard. Usually I just kill the controlling shell
>and getty cleans up the mess :-)
Its something around this perhaps.
UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND
1001 65053 65051 0 18 0 1372 1012 pause Is p4 0:00.07 -tcsh
(tcsh)
0 65062 65053 255 4 -2 1020 648 ttywri I<+ p4 0:00.01 su
ps -auxt v0
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
root 337 0.0 0.0 0 0 v0- Z - 0:00.00 (login)
When I physically went to the machine this morning, V0 was indeed hosed and
in a zombie state. Is this co-incidence ? Is there anyway to simulate
this issue so that I can see if the behaviour is repeatable ? Would it be
because syslog is trying to write to the console and the process is getting
stuck there ? Hmmm
Ah ha!
I just went to the machine and killed syslogd, and the problem is fixed! I
guess su was writing to syslogd a "BAD su to root" message, but syslogd
could not write to /dev/console because the console getty was hosed on
ttyV0 and su just wait there indefinitly.
I havent thought about it enough, but is there a potential for a little
denial of service ? At the very least, should su get stuck waiting for
syslog to do its thing like this ? I would say not, as I was locked out of
my box temporarily until I was able to physically get to it this morning
and login directly as root.
---Mike
------------------------------------------------------------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications mike@sentex.net
Cambridge, Ontario Canada www.sentex.net
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.5.32.20000511125540.019f1ea0>