startx - client 1 rejected from local host

rv8 · 07-16-2002, 07:31 PM

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 · 07-17-2002, 03:50 AM

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-use.../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 · 07-17-2002, 05:11 AM

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':

Code:

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).

Code:

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:

Code:

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 · 07-17-2002, 06:14 AM

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 · 07-17-2002, 06:20 AM

rv8,

From the 'man xhost' pages:

Code:

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.

Code:

[+]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.

07-16-2002, 07:31 PM	#1
rv8 Triple-A Player Join Date: Mar 2002 Location: Ottawa, Canada Posts: 88	startx - client 1 rejected from local host 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 __________________ Kevin Horton http://www.kilohotel.com/rv8/

07-17-2002, 05:11 AM	#3
sao Moderator Join Date: Jan 2002 Location: Singapore Posts: 4,233	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': Code: 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). Code: 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: Code: DisplayManagerauthorize: 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... Last edited by sao; 07-17-2002 at 06:00 AM.*

07-17-2002, 06:14 AM	#4
rv8 Triple-A Player Join Date: Mar 2002 Location: Ottawa, Canada Posts: 88	Thanks! 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 __________________ Kevin Horton http://www.kilohotel.com/rv8/

07-17-2002, 06:20 AM	#5
sao Moderator Join Date: Jan 2002 Location: Singapore Posts: 4,233	rv8, From the 'man xhost' pages: Code: 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. Code: [+]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. Last edited by sao; 07-17-2002 at 06:33 AM.

Thread Tools
Show Printable Version Email this Page
Display Modes	Rate This Thread
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode	Rate This Thread:

07-17-2002, 03:50 AM	#2
sao Moderator Join Date: Jan 2002 Location: Singapore Posts: 4,233	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-use.../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 Last edited by sao; 07-17-2002 at 04:36 AM.