"The Linux Gazette...making Linux just a little more fun!"

login, su, and passwd dies: Everybody dies!

From Tim Kientzle on Mon, 11 Oct 1999

I'm having a hard time finding good technical archives for Linux. I've been searching 'linux login' trying to find someone else who's had this problem; I stumbled across a couple of your columns in the process.

In any case, I have a useful factlet for you regarding login problems: The KDE 'add user' program by default does not assign a login shell. Thus, accounts that cannot be logged into.

For myself, I have a RedHat 6.0 machine that does not accept any logins, not even root. It never gets to a password prompt. This is true of getty, telnet, ftp, and KDM logins. I brought the machine up in single-user mode, and found that 'su' and 'passwd' both crash, also. It looks as though any program that needs to touch the password file simply dies at that point. (Note that 'su' does not crash if you use it to go from root to a non-root user.)

Oddly enough, this problem arose spontaneously; the machine has worked fine (about 8 functioning accounts) for a week. I came in this morning, and tried to telnet into that machine; the connection dropped at the telnet prompt. I rebooted the machine (which required hitting the big red button, since I can't login as root to safely shut down) and then KDM won't come up; it seems to crash the X server. No useful messages to /var/log/messages, just a machine that can't even be reasonably debugged.

I'm almost ready to drop RedHat and go with FreeBSD instead. <sigh>

- Tim Kientzle

It sounds like massive corruption to your libraries or to your /etc/passwd file. I'd start by booting from a rescue diskette (as you've already done once) and editing the /etc/passwd and /etc/group files.

If those look alright (compare their formatting to the ones on your rescue floppy) then check the /etc/shadow file. You could just rename the etc/shadow file and try the 'passwd' command again.

(The libraries use the existence of an /etc/shadow file as a hint to use shadow passwords).

Another thing to try is the following commands:

cd /mnt/ && usr/sbin/chroot . /bin/sh rpm -Va

(or, if you have a copy of the 'rpm' command on your resuce diskette you can use: 'rpm --root /mnt -Va')

This rpm command will check the integrity of the system files, libraries and binaries, and the ownership, modes, and other particulars for every file that included in any package you installed.

You can use the 'rpm -qf' command to match the filenames that the verification reports to the package names that you might need to re-install.

Of course you could re-install from scratch. However, it would be very unsettling to me to do that with no understanding of what went wrong. I suspect that you feel the same; how can you trust a system that "did that" all of a sudden.

One possibility is that your system was cracked (incompetantly). The programs you mention are some of the same ones that are replace by most "rootkits." If some script kiddie broke into your system and tried to install a rootkit that was pre-compiled for libc5 then I could see it give symptoms just like those you've described.

The 'rpm -Va' command might uncover this. Script kiddies and their canned cracker tools don't seem to have added "rpm dbm patchers" YET. However, it's only a matter of time before they do.

In a past issue(*) I've described more robust techniques for using write-protected boot floppies, you original CD, the rpm command and some shell utilities to perform a system integrity audit on a Red Hat or other RPM based system. That article was long-winded since I explained the method in some detail.

• (http://www.linuxgazette.com/issue37/tag/44.html search the page for "pkg.inst") As for running FreeBSD: It's a nice system. It's a bit more carefully integrated then most Linux distributions and it can run most Linux binaries. I've suggested that intermediate and advanced Linux users give it a try some time (next time you're about to install an OS on a new machine and you have a couple of days to "tinker" with it).

You might also try Debian. I'm slowly switching my home systems and laptop over to it. I just got my new personal workstation up and running this weekend, got my home directory tree (700Mb, mostly of e-mail archives) transferred and have spent all day answer e-mail on it.

Let me give an example of what I like about Debian.

I chose a minimal installallation to start with (about 100Mb total. I upgraded it from the CD version to the latest version of everything in "unstable" by editing one file (/etc/apt/sources.list) and issuing one command (apt-get update && apt-get dist-upgrade -f). It sucked down 120 packages from the 'net and put them all in place.

Then I installed a curses package selection tool (console-apt) and used that to select a few other programs that I wanted (things like xemacs). apt-get and console-apt use the same selection database, and use the dpkg command under the hood. They automatically get any libraries and ancillary packages to resolve dependencies.

Later, after I'd transferred all of my home directory files, I starting working like I prefer (running xemacs, in viper-mode under 'screen'). At some point I typed a word that look "wrong" and I hit [F3][$] (my personal xemacs macro for spell-checking the word under my cursor). Ooops, ispell wasn't installed!

So I switch to another VC, type:

apt-get install ispell iamerican

... wait about 30 seconds and go back to my editing. my spell check now works.

Another time a few weeks ago I was answering a question about LPRng. I logged into my other Debian system (a little file and mail server, antares), installed the package, read the doc page I was looking for, and removed it. That was faster than hunting for it in Yahoo!

That's what I like about Debian. I've been doing that sort of thing for months on my machine at the office.

In fairness to Red Hat and it's ilk, the 'rpmfind' command (http://rufus.w3.org) makes RPMs almost as easy to manage. However, debian does have a lot more packages and apt-get seems more stable than rpmfind.

So far the Debian apt-get facility is the only one that I've ever trusted with automatic system upgrades. I've been running regular dist-upgrades on my box at work for months --- on the UNSTABLE development series, the betas --- and I haven't broken my system yet (sometimes one or two packages get a bit messed up; but nothing that's caused real problems).

Meanwhile Debian is not for the UNIX novice. Most users would not know that xemacs and emacs call on a program named 'ispell' and most wouldn't know that the various dictionary/wordlist files for ispell are named like iamerican, ibritish, etc. While Debian has more packages, part of this is because they them to a finer granularity. They don't put an IMAP daemon and a POP daemon in the same package. Also many of the Debian packages are alternatives or are fairly obscure. They are the sort of thing that

Of course the FreeBSD "ports" system is also pretty good. I'd still like to see something like it for Linux. (It gets the prize for most comprehensive use of the 'make' command).

Anyway, I hope you track down the problem. If it does turn out to be a cracker, be sure to get the latest security fixes when you re-install. There have been a number of bugs with wu-ftpd and ProFTPd recently and they are being actively exploited. (Fixes for the known bugs are at the Red Hat updates site, and at the archive sites for most other Linux distributions.

As usually you should disable any services that you don't absolutely need to run, limit access to your non-anonymous services (using TCP Wrappers and/or ipchains) wherever that's possible, replace 'telnet' support with 'ssh', 'ssltelnet' or 'STEL', use shadow passwords, etc.

Read the Security-HOWTO (http://www.linuxdoc.org/HOWTO/Security-HOWTO.html) and the Linux Administrator's Security Guide (http://www.seifried.org/lasg) for lots of details on that.

Copyright © 1999, James T. Dennis
Published in The Linux Gazette Issue 48 December 1999

HTML transformation by Heather Stern of Starshine Technical Services, http://www.starshine.org/

					1	2	3	5
				5	6	7	8	9
10	11	12	13	14	15	16	17	18
19	20	21	22	23	24	25	26	27
28	29	30	31	32	33	34	35	36
37	38	39	40	41	42	43	44	45
46	47	48	49	50	51	52	53	54
55			56			57