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>