help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Help me with Emacs


From: Tim X
Subject: Re: Help me with Emacs
Date: Sat, 14 May 2005 18:24:49 +1000
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)

"Ronit Tajian" <address@hidden> writes:

> Hi,
> I downloaded Emacs 21.4 from
> ftp://ftp.gnu.org/gnu/emacs/emacs-21.4a.tar.gz under Linux.
>
> Followed the instructions in the INSTALL text to install
> it. Everything seems to went fine. When trying to run or open the
> Emacs receive this error:
> ---------------------------------------------------------------
> Xlib: connection to ":0.0" refused by server
> Xlib: No protocol specified
>
> emacs: Cannot connect to X server :0.0.
> Check the DISPLAY environment variable or use `-d'.
> Also use the `xhost' program to verify that it is set to permit
> connections from your machine.
> -------------------------------------------------------------------------------------
>

This error generally indicates the user you are logged in as does not
have permission to write to your X display. There are lots of possible
causes for this, but a common one is due to you using su to login as
another user and then try to run an X application as that user. 

The X windows system uses a 'magic cookie' to control access to the X
display. Most modern linux distributions set this up automatically
(see the xauth man page). The xauth system places the magic cookie in
a file in the users home directory - usually called .Xauthority. When
you try to run an X based appication, the X server checks to see if
you have a valid cookie and only allows connections if one exists. 

Users sometimes get caught here when installing new software. For
example, you decide to install emacs from the tar ball into
/usr/local/someplace. As you need to be root to write to this part of
the filesystem, the user does and 'su -' and as root downloads the
sources into /usr/local/emacs-21.4 (or whatever). Then cd's to that
directory and does the build. When completed (and usually) before
installing the binary into /usr/local/bin  etc, the user tries running
the newly build emacs by executing the 'emacs' command. Then they see
the error message you get. The problem is that the X server has
checked to see if the user has a valid xauth cookie in their home
directory, but because they are running as root, the root home
directory is checked and there is no valid cookie available. The
result is the connection is refused and you see the error message you
are getting. 

There are a number of solutions to this problem. The easiest thing to
do is try testing the new emacs as the user your logged into X as, not
as root. Change to another xterm and run emacs or exit from root and
try running it.

If you still get the error, then something else is wrong. I don't
believe its your DISPLAY setting as this would prevent xterms from
running. You will need to dig deeper.

Note that you should not use the xhost command as suggested in the
error message - xhost creates a security hole. Although this is
probably not a concern on a single user system, it could be a concern
on a multi user system. The problem with xhost is that it is a host
based authorisation system. If you use xhost to allow connections to
your X display, it will allow anyone on that host to connect to your X
display. This could allow someone to install a sniffer which captures
keystrokes entered in the X session. A safer solution is to either
only run X apps as the user logged into the X session or merge your
Xauthority file with the Xauthority file of the other user you want to
grant permission to access your X display to. The X Windows
distribution use to come with a script call xon (or Xon) which did
this using rsh. It is trivial to re-write this script to use ssh/scp -
if you only want this capability on the local host, you can achieve
the same sort of thing just using cp. It would be quite trivial to
write your own su wrapper script which could do this automatically -
in fact, I think GNOME is often configured to do this automatically. 

-- 
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you 
really need to send mail, you should be able to work it out!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]