"The Linux Gazette...making Linux just a little more fun!"

Permission Denied on -display

From Berkeley F Bernard on Wed, 29 Mar 2000

I can rsh to various hosts and run text screens but I cannot seem to get the -Display to work. It always comes back permission denied.

I have tried various hosts.allow, .rhost and inetd.conf setting to no avail.

Is there a proper setup for these files? Is there a debug setting that will tell me why permission denied is being return?

Thanks

Short answer: USE ssh! (More on that later).

My 'rsh' command doesn't have a "-Display" (nor a -D nor a -display, etc). However, I'm going to go out on a limb here and guess that you are running a local X server, and that you are trying to get your 'rsh' command to launch a remote X client.

The reason that the graphics program that you run on your Linux or other UNIX system is called an "X Server" or a "display server" is because the X Windowing System is actually a communications protocol.

In the field of computing servers share resources among clients. A file server allows a set of clients to share files and and the storege/disk space that they occupy. A print server allows a set of clients to share a printer -- it spools and schedules their print jobs, possibly dispatching them to multiple printers, and handing various matters of form (requiring an operator to mount of the proper forms, or running tray changers, collators, etc).

An X display server allows a set of clients to share a display. It lets programs take over a portion of your screen (they get one or more into, into which they can draw whatever they like). The X server also dispatches input to these clients, feeding them keyboard and mouse events. That is the basic programming model for X, the client/server windowing system.

One consequence of this is that the clients don't have to be on the same system as the server. It is sufficient that they have a means of communication. The most common form of communication among X servers and their remote clients is TCP over port 6000, 6001, etc.

Naturally it is necessary for the X server to impose some form of authentication and authorization on its clients. It just wouldn't be very handy if any user on any system on the Internet could just start popping windows up on your display, and it would be darn right ugly if they could start "invisible" applications that requested notification of all keyboard, mouse, and other events occuring through your server.

So, your X server defaults to only honoring requests from your local processes. You can over-ride this policy, and extend those services to other accounts on other systems using any of three common mechanisms. I'll describe two of them for your edification, then I'll forward you another bit of mail (an answer to another Answer Guy question) that will hopefully convince you to just use 'ssh'

The first and worst means to loosen control over your X server is to use the 'xhost' command. If you simply issue the command:

xhost +

... from an xterm within your X session you will have opened your X server to the whole world. DON'T DO THIS! If you issue a (slightly) more conservative command like:

xhost +foo.bar.not

... you'll be allowing any user on foo.bar.not to access your X server. This is "slightly" better. Unfortunately you'll also be allowing any user on any system that can "spoof" packets so the look like the "might have come from" foo.bar.not to access your X server. I think this is a bad idea, though I'll admit that I've done it around the house, before I had a DSL line.

Did I say "loosen control" to your X server? Maybe that should just read "lose control."

There's a technique you can use to control access to your X server. On any reasonably modern and well packaged Linux distribution you should find that your X server is actually started with a -auth command line option. This points the server at an "X authority file" (Usually that contains an "MIT Magic Cookie").

A what?!? A Magic cookie.

Here's how this works. When any X client program tries to perform any X functions (using the X protocol) it searches its environment for a DISPLAY value. (It might also look on its command line, or in it's own *rc files, or whatever). Finding that it tries to connect to the server.

When it connects the X server might request a "cookie." (Sort of a "password of the day"). The X client will then search for an XAUTHORITY environment variable. If one exists, its value is presumed to be a file name; if not, the UNIX or Linux client will probably look for a file named .Xauthority, in your home directory. Thus the X client will open that file, search for the matching cooking (one X authority file might have several cookies in it), extract that and feed it to the X server that made the request.

Notice that all of this is done transparently by the libraries. You, as a user needn't be away of that process, so long as your XAUTHORITY variable is set, and your ~/.Xauthority file has the valid cookie, then you don't need to fuss with anything.

If you have an account in a NIS or HESIOD system, and your home directory is on a network fileserver, then it's possible that you'd never have to worry about these .Xauthority files. As you start X servers the appropriate cookies would be added to your .Xauthority file. As you rsh or telnet to remote systems your home directory is mounted (and the .Xauthority file is thus accessible to those client processes). The file permissions can be used to prevent other users from reading your .Xauthority file, and thus they cannot extract the cookie and feed it to your X server.

When you don't have your home directory on a shared filesystem, it's still possible to use these magic cookies. You just have to extract the appropriate cookie from your local server, pass it to the remote system (possibly through an rsh pipe), and merge it into the .Xauthority file there. The command that does all this extracting, adding, merging and listing is called 'xauth'.

You can think of the .Xauthority file as a sort of "archive of passwords" and the 'xauth' as analogous to 'tar' for them. Well, sort of.

Anyway. That's basically how the 'xauth' system works.

It's about as secure as telnet. It does essentially require a password for access to the X server, without bothering the user to keeping typing it for every program they launch.

There is one tiny problem. The X protocol doesn't use any encryption. Therefore, unless you were using something like IPSec, these exchanges between remote clients and servers could be sniffed (deliberately overheard) by anyone on your LAN. (I won't bother covering the affect of etherswitches on this scenario --- other than to say that it doesn't buy as much as their purveyors would suggest).

The X authority model, with its magic cookies is workable. If you search through the "Remote X Apps mini-HOWTO" (https://www.linuxdoc.org/HOWTO/mini/Remote-X-Apps.html) you can find out more info.

However, this is all unnecessary if you use ssh. I've just answered a rather similar question earlier tonight; so I'll just forward you a copy of the salient portions from my reply. The mini-HOWTO that I've referenced above also covers this (somewhat more briefly).

Hope that helps.

Copyright © 2000, James T. Dennis
Published in The Linux Gazette Issue 52 April 2000

HTML transformation by Heather Stern of Tuxtops, Inc., https://www.tuxtops.com/

					1	2	3	4
				5	6	7	8	9
10	11	12	13	14	15	16	17
18	19	20	21	22	23	24