Xwindows

'Robin' R. Battey zanfur at u.washington.edu
Wed Mar 28 19:17:29 PST 2001


Ben:

If your machine is not firewalled, I highly suggest you scan it using nmap
or an equivalent to see if it's been hacked. If it hasn't crashed, and
you didn't alter any configurations, then someone else did. I can scan it
for you if you like (but I'd need the ip address), I know what to look
for.

If you want to look at the differences between runlelvel 3 and runlevel 5,
you can look at /etc/inittab (read "man inittab" for an explanation).
The individual startup scripts that are run are in /etc/rc<runlevel>.d
for each <runlevel> from 0 to 6, and the list of all scripts is in
/etc/rc.d/init.d (on redhat machines -- on debian and other variants it's
in /etc/init.d). The major difference between runlevel 5 and runlevel 3,
by default, is that init calls prefdm (which in turn runs either xdm or
gdm on the console). The reference to prefdm is in /etc/inittab, near the
end of the file.

If xdm/gdm is crashing while doing the xauth routine, you'd have a stray
lock on ~/.Xauthority. And if it crashed once and corrupted
~/.Xauthority, it will probably crash again. "startx" doesn't actually
run gdm or xdm, it just starts X and then starts the session. "startx" is
actually one big large script you can modify, check it out if you're
interested. Gdm and xdm don't run startx, but they spawn most of the same
processes. The idea here is that gdm != startx, and they handle the
authorization different ways. If I had to hazard a guess, I'd say that
your xdm/gdm was hosed.

In brief:

When you start prefdm, it starts X, then starts xdm or gdm on the console
(and wherever else you've configured it to). During it's authorization
(setting up so that only your processes can use the screen), it accesses
and modifies ~/.Xauthority. It appears that the write lock is not getting
released when the process crashes (which is very bad--the kernel should
reap locks when that happens, regardless of how the process dies). You
try to run startx afterward, and the lock is still on the authority file.

There are two possible reasons for this: either the process that is
accessing ~/.Xauthority is still running, or your kernel is buggy. If you
have case one, just kill the process (kill -9 if necessary). If you have
case two, you're in serious trouble--upgrade your kernel.

To get information:

Use "lsof" (list open files) to find out what processes have what files
open (for instance, if you want to kill all processes with ~/.Xauthority
open).

Use "lslk" to list locks on files (for instance, if you want to know if a
previously run process has left any locks hanging around).

As I mentioned earlier, if you're attached to an un-firewalled network, I
highly encourage you to check for hackers. Most of the time, when things
go strange like this, it means that someone else is root on your box.

Hope some of this helps. Cheers!
-robin

P.S. -- also check the permissions on /dev/console, they should be 0600,
owned by you. Also, make sure that you are *not* su'ing to anybody, or it
won't give you the console.

On Wed, 28 Mar 2001, Benjamin Honsinger wrote:


> Something strange is happening. I have a computer that before today worked

> fine, and nothing has been changed on it. It is setup to start on runlevel 5,

> and that works. However, when you login, it looks like it is going to work

> (changes screen, etc) but it switches back to the graphical login.

> So I tried booting in runlevel 3, but then when I type startx I get

>

> xauth: error locking /home/student/.Xauthority

> hostname: unknown host

> Perhaps you do not have console ownership?

>

> The same thing happens when I try and run x as root, except it doesn't ask the

> question about console ownership. This has me stumped. I've nosed around on the

> Xfree86 web page, and in the LDP, but I haven't found anything useful. Anyone

> have some suggestions I could try, they would be appreciated! =) Just as a

> note, it if matters I think I am running dangerously low on disk space. And

> also, I believe the error X gives is errno 111.

>

> - Ben

>




More information about the Linux mailing list