startx - client 1 rejected from local host

[rv8]

Two days ago I started having problems with X11. It worked fine three days ago, but now I get:

[cube:~] kwh% startx -- -quartz

2002-07-15 14:45:27.864 XDarwin[369]
XDarwin 1.1
Running in parallel with Mac OS X Quartz window server.

XFree86 Version 4.2.0 / X Window System
(protocol Version 11, revision 0, vendor release 6600)
Release Date: 18 January 2002
If the server is older than 6-12 months, or if your hardware is
newer than the above date, look for a newer version before
reporting problems. (See http://www.XFree86.Org/FAQ)
Operating System: Darwin
Using keymapping provided in /System/Library/Keyboards/USA.keymapping.
_XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root
Display mode: Rootless Quartz
Screen 0 added: 1024x747 @ (0,21)
Screen 0 placed at X11 coordinate (0,0).
AUDIT: Mon Jul 15 14:45:36 2002: 369 XDarwin: client 1 rejected from local host
Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified


waiting for X server to begin accepting connections .
AUDIT: Mon Jul 15 14:45:38 2002: 369 XDarwin: client 1 rejected from local host
Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified

..

The last series of lines repeat apparently indefinitely.

I restarted the computer - no improvement.

I did a fink reinstall for all the packages that I thought were relevant, just in case something had gotten corrupted (xfree86-base, xfree86-rootless, windowmaker and windowmaker-shlibs). This didn't help.

The only thing I had changed lately was that I edited /etc/sshd_config to enable X11Forwarding. I disabled it again just to check, but that made no difference.

I also have been updating fink's packages regularly to the unstable CVS tree as changes come out, but I can't recall seeing any packages to update lately that I think are relevant.

So, can anyone offer any suggestions as to what files to look at, or which packages to reinstall, etc?

[cube:~] kwh% fink --version
Package manager version: 0.9.12
Distribution version: 0.4.0.cvs

fink's packages updated regularly from unstable tree, cvs

OS X 10.1.5
Dec 2002 Developer Tools

relevant packages installed:
i windowmaker 0.80.0-7 GNUstep (NeXT-like) Window Manager
windowmaker-dev 0.80.0-7 GNUstep (NeXT-like) Window Manager
i windowmaker-shl 0.80.0-7 GNUstep (NeXT-like) Window Manager
i xfree86-base 4.2.0-6 XFree86 libraries, utilities, clients and d...
i xfree86-rootles 4.2.0-2 MacOS X/Darwin XFree86 display server.

Thanks,

Kevin Horton

[sao]

rv8,

I also read your post at the fink-users list on 04 May 2002 with a similar problem.

Well, I guess you already followed 'Jeff Whitaker advice' for that problem before:

http://www.mail-archive.com/fink-users@lists.sourceforge.net/msg02536.html

and tried by blowing out your .Xauthority file in your home directory.

By your answer to that post, it looked like it worked, and now the problem comes back again?

Please, post a copy of your ~/.cshrc file.

I figure that something is wrong with your settings. Let's investigate further as it seems that your DISPLAY environment variable wasn't accepted somehow.

Cheers...

Edited

[sao]

rv8,

Well this is out from the scope of fink, but I checked the following:

Check the chapter 'Xauth' and 'Troubleshooting' from:

http://www.xs4all.nl/~zweije/xauth.html#toc5

"The client could make a connection to the server, but the server does not allow the client to use it (not authorized). Make sure that you have transported the correct magic cookie to the client, and that it has not expired (the server uses a new cookie when a new session starts)."


And please, read 'man xauth':

DESCRIPTION
The xauth program is used to edit and display the authorization information
used in connecting to the X server. This program is usually used to extract
authorization records from one machine and merge them in on another (as is the
case when using remote logins or granting access to other users).

The most common use for xauth is to extract the entry for the current display,
copy it to another machine, and merge it into the user's authority file on the
remote machine:

% xauth extract - $DISPLAY | rsh otherhost xauth merge -

The following command contacts the server :0 to create an authorization using
the MIT-MAGIC-COOKIE-1 protocol. Clients that connect with this authorization
will be untrusted.
% xauth generate :0 .

Users that have unsecure networks should take care to use encrypted file transfer mechanisms to copy authorization entries between machines. Similarly, the MIT-MAGIC-COOKIE-1 protocol is not very useful in unsecure environments. Sites that are interested in additional security may need to use encrypted authorization mechanisms such as Kerberos.

Normally, xauth is not used to create the authority file entry in the first place; xdm does that. Checking also with 'man xdm' will give you more details.

The X Display Manager, xdm, is a client which provides login screens for multiple X Servers. When a user logs in through the X Display Manager, xdm writes a magic cookie to the user's home directory, in the file .Xauthority.

In addition to providing a more user friendly login sequence, xdm provides support for magic cookie authentication. This authentication must first be turned on by the following X resource entry in the file /usr/lib/X11/xdm/xdm-config:

DisplayManager*authorize: true

With this, xdm will generate a new magic cookie value each time a user logs in, and store that value in their .Xauthority file.

Please study the information at the following web page:

http://ciac.llnl.gov/ciac/documents/ciac2316.html#2.0

Let me know what comes out.


Cheers...

[rv8]

Sao,

Thanks so much. I had completely forgotten about the fact that I had this problem before. I did a goggle search on my error message, but none of the hits were relevant. I never even thought to also search the fink list archives.

Problem solved!

Kevin

[sao]

rv8,

From the 'man xhost' pages:

The xhost program is used to add and delete host names or user names to the
list allowed to make connections to the X server. In the case of hosts, this
provides a rudimentary form of privacy control and security.

[+]name
The given name (the plus sign is optional) is added to the list
allowed to connect to the X server. The name can be a host name or a
user name.

Using the xhost program is straightforward. Each X server maintains a list of hosts which may or may not access it. The xhost program is used for modifying that list. The command line syntax is as follows:

Display a list of hosts allowed to access this X Server:

xhost

To add a host, say bar.foo.org, one would type:

xhost +bar.foo.org

Then, any user and program on that machine may communicate with your X server.

To remove that same host, type:

xhost -bar.foo.org

An X server may be opened to the world by disabling access control:

xhost +

Access control may be re-enabled (i.e., the current list of hosts is again active) by:

xhost -


When xhost is utilized, a user from an unauthorized host attempting to connect will be presented with the following response:

Xlib: connection to "display:0.0" refused by server
Xlib: Client is not authorized to connect to Server

Note that disabling a host's access after a connection has been made will have no effect on existing connections. The server must be reset in order to break established connections.

The simplicity of xhost is both a benefit and a drawback. All connections from a host must be accepted or rejected-not on a user-by-user, program-by-program, or connection-by-connection basis. For many environments, where numerous users are allowed access to a particular host, this is an insufficient solution. And certainly, most computers running X servers have multiple user accounts, and any user that can log in to the computer can access the X server, as the localhost, completely bypassing the xhost access control.

Unfortunately, many X servers, such as NCD servers, SGI systems, and Mac X for the Macintosh come with access control disabled by default. For users unfamiliar with the vulnerability of X servers, this can create a real security problem.

Xhost has higher priority than token authentication. Any user can add systems to the xhost access list without special privileges or assistance from the system administrator.

Hope all this info can help you to solve your problem.

Good luck.


Cheers...

PS: Just read your last post, Glad you solved it with the old advice.
I would suggest nevertheless you study all this info, so that maybe, you can avoid it happening again.