Why xhost +1?
The magic word is DISPLAY. In the X window system, a display consists (simplified) of
a keyboard, a mouse and a screen. A display is managed by a server
program, known as an X server. The server serves displaying capabilities to other
programs that connect to it.
A display is indicated with a name, for instance:
DISPLAY=light.uni.verse:0
DISPLAY=localhost:4
DISPLAY=:0
The display consists of a hostname (such as light.uni.verse and localhost), a colon
(:), and a sequence number (such as 0 and 4). The hostname of the display
is the name of the computer where the X server runs. An omitted hostname means the
local host. The sequence number is usually 0 -- it can be varied if there
are multiple displays connected to one computer.
If you ever come across a display indication with an extra .n attached to it, that's
the screen number. A display can actually have multiple screens. Usually
there's only one screen though, with number n=0, so that's the default.
Other forms of DISPLAY exist, but the above will do for our purposes.
For the technically curious:
? hostname:D.S means screen S on display D of host hostname; the X server for this
display is listening at TCP port 6000+D.
? host/unix:D.S means screen S on display D of host host; the X server for this
display is listening at UNIX domain socket /tmp/.X11-unix/XD (so it's only
reachable from host).
?:D.S is equivalent to host/unix:D.S, where host is the local hostname.
7.3 Telling the Client
The client program (for instance, your graphics application) knows which display to
connect to by inspecting the DISPLAY environment variable. This setting
can be overridden, though, by giving the client the command line argument display
hostname:0 when it's started. Some examples may clarify things.
Our computer is known to the outside as light, and we're in domain uni.verse. If we're
running a normal X server, the display is known as light.uni.verse:0.
We want to run the drawing program xfig on a remote computer, called dark.matt.er, and
display its output here on light.
Suppose you have already telnetted into the remote computer, dark.matt.er.
If you have csh running on the remote computer:
dark% setenv DISPLAY light.uni.verse:0
dark% xfig &
or alternatively:
dark% xfig -display light.uni.verse:0 &
If you have sh running on the remote computer:
dark$ DISPLAY=light.uni.verse:0
dark$ export DISPLAY
dark$ xfig &
or, alternatively:
dark$ DISPLAY=light.uni.verse:0 xfig &
or, of course, also:
dark$ xfig -display light.uni.verse:0 &
It seems that some versions of telnet automatically transport the DISPLAY variable to
the remote host. If you have one of those, you're lucky, and you don't
have to set it by hand. If not, most versions of telnet do transport the TERM
environment variable; with some judicious hacking it is possible to piggyback
the DISPLAY variable on to the TERM variable.
The idea with piggybacking is that you do some scripting to achieve the following:
before telnetting, attach the value of DISPLAY to TERM. Then telnet out. At
the remote end, in the applicable .*shrc file, read the value of DISPLAY from TERM.
The server will not accept connections from just anywhere. You don't want everyone to
be able to display windows on your screen. Or read what you type --
remember that your keyboard is part of your display!
Too few people seem to realise that allowing access to your display poses a security
risk. Someone with access to your display can read and write your
screens, read your keystrokes, and read your mouse actions.
Most servers know two ways of authenticating connections to it: the host list
mechanism (xhost) and the magic cookie mechanism (xauth). Then there is ssh, the
secure shell, that can forward X connections.
7.4 Xhost
Xhost allows access based on hostnames. The server maintains a list of hosts which are
allowed to connect to it. It can also disable host checking entirely.
Beware: this means no checks are done, so every host may connect!
You can control the server's host list with the xhost program. To use this mechanism
in the previous example, do:
light$ xhost +dark.matt.er
This allows all connections from host dark.matt.er. As soon as your X client has made
its connection and displays a window, for safety, revoke permissions for
more connections with:
light$ xhost -dark.matt.er
You can disable host checking with:
light$ xhost +
This disables host access checking and thus allows everyone to connect. You should
never do this on a network on which you don't trust all users (such as
Internet). You can re-enable host checking with:
light$ xhost -
xhost - by itself does not remove all hosts from the access list (that would be quite
useless - you wouldn't be able to connect from anywhere, not even your
local host).
Jonathan Wilson wrote:
> Hey,
>
> I'm accessing one of our servers with VNC and it's giving me this error when I try
>to open up a su - 'd wterm for GUIs:
>
> [root@garnet /root]# xhost +l
> Xlib: connection to "garnet.graphics:20.0" refused by server
> Xlib: Client is not authorized to connect to Server
> xhost: unable to open display "garnet.graphics:20.0"
>
> Any idea why that is? It works quite well as the initial user (jw) but after I su,
>it won't xhost. If anyone has an idea why not I'd like to hear from ya.
>
> If I just do it as jw it works fine, as follows:
>
> [jw@garnet jw]$ xhost +localhost
> localhost being added to access control list
>
> ----------------------------------------------------
> Jonathan Wilson
> System Administrator
>
> Cedar Creek Software
> http://www.cedarcreeksoftware.com
>
> Central Texas IT
> http://www.centraltexasit.com
>
> _______________________________________________
> Redhat-list mailing list
> [EMAIL PROTECTED]
> https://listman.redhat.com/mailman/listinfo/redhat-list
_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list
