|< Day Day Up >|| |
One of the most powerful features of the X Window System is its networking support. The X Window System was designed to run in a networked environment. If you are a system administrator responsible for a number of RHEL 3 systems, you don't have to run to the server room every time you want to run a GUI administration tool. With the X Window System, you can connect to any number of systems and redirect the output from X Clients running on those systems back to the X Server running on your desktop.
Before we configure clients and servers to transmit graphical applications, let's examine some of the basics of X Window security. When working with remote X applications, all other Linux security features are still in effect. You will still need a user account and password in order to connect to the remote system to start an X Client. You need to make sure that a firewall isn't blocking access.
Part of the job of the X Server running on your local computer is to listen for requests from X Clients that want to send their output to your display. Those requests can come from applications that are running on your local computer, or they can come from applications running on another computer on your network.
You need access control. Otherwise, anyone on your network can send the display from their X Clients to your computer. In a larger or a production network environment, you will want to limit access to your local X Server.
The Linux way to control access to your local X Server is with the xhost command. This command controls access by computer. In Table 6-3, I illustrate a number of examples of how you can use the xhost command to secure your X Server. You can substitute IP addresses for specific computer hostnames.
Show current security settings
Disable security; allow connections from any system
Allow connection from apps.xyz.com
Disable connections from apps.xyz.com
The xhost command allows you to control X Server security on your computer. One more sophisticated alternative is the xauth command, which can use encryption to verify not just remote computers, but the permissions that you may grant to remote users. Access information for these other validation methods is stored in the hidden binary file ~/.Xauthority.
|Exam Watch|| |
These xhost commands won't work unless you're running them from a command line terminal inside the Linux GUI. Otherwise, you'll get an error message like 'unable to open display.'
Before you can send X Clients from a remote computer, you need to set the DISPLAY variable. You can do so with a command such as DISPLAY=localhost:0.0. Then you can export that variable with the export DISPLAY command. Alternatively, you can combine the two commands with the following command:
# export DISPLAY=xserver:0
where xserver is the name of the remote computer where you want the X Client to be shown.
The second part of the DISPLAY line (0.0) requires further explanation. As described earlier, you can start multiple X Servers. When you are redirecting the output for an X Client, you must tell it not only which system to connect to but also which GUI display and which screen on that display to use. On most systems this will be servername, display 0, console 0 (written as host:0.0). The server portion of this entry can be a hostname, a fully qualified domain name, or an IP address. The following are all valid specifications for remote displays:
To summarize, there are three steps required before you can run X Clients from remote computers:
Disable the firewall on the local computer, the X Server, with a command such as service iptables stop.
Authorize connections from the remote computer. For example, for a remote computer named charlie, you'd run the xhost +charlie command.
Log into the remote computer and export the DISPLAY variable.
But there's an easier way. Using the Secure Shell (ssh) described in Chapter 11, you can log into the remote client computer. You can then start X Clients such as xterm or even a Red Hat GUI tool such as the Security Level Configuration tool described in Chapter 10 with the redhat-config-securitylevel command. The GUI application opens automatically on the local computer.
You still need to authorize access from the local computer with an appropriate xhost command, as I've just described.
Exercise 6-4: Starting a Display from a Remote Client
In this exercise, we'll look at the steps required to run a display from a remote client. This assumes a basic knowledge of the Secure Shell, and its associated command, ssh. For more information on running the ssh command, see Chapter 11. You'll need two computers running Linux. While RHEL 3 is not required on both computers, you will need the Secure Shell installed on both. The Secure Shell service, sshd, should be running on the remote computer. You'll also need the root password for both computers. Assume the local computer is named Enterprise, and the remote computer is named cosmicc (which is short for Cosmic Charlie, my favorite Grateful Dead teddy bear).
On the Enterprise computer, start the X Window. If it isn't already open, use the startx command.
When the Linux GUI is open, right-click on the desktop. In the pop-up menu that appears, click New Terminal.
Log into the remote computer using the Secure Shell. To log in as root, use the following command. Enter the root password on the remote computer when prompted. If you're asked if you want to set up a encryption key, type yes. This should log you into the remote computer.
# ssh root@cosmicc root@cosmicc's password:
Now you can start the GUI applications of your choice. Start with some easy X Clients, such as xterm, xclock, and xeyes. Where do you see these clients displayed? If you have the GUI open on the remote computer, you can walk over there and check the other computer for yourself. Close whatever X Clients you open.
You should be able to run most of the Red Hat GUI utilities from the remote computer. Try some with commands such as redhat-config-network, redhat-config-samba, and redhat-config-securitylevel. You can now edit the configuration on the remote computer. Remember to close the GUI utilities that you open.
If you run any remote GUI configuration utilities, check the results in the appropriate configuration file.
The X Window System is very robust and stable, but occasionally problems can arise. You can try several things when you troubleshoot X Window problems:
Session managers create log files in your home directory such as ~/.xsession-errors. Check these log files as well as /var/log/messages and /var/log/XFree86.0.log for error messages from your X Server.
Check the DISPLAY environment variable to make sure it is set correctly. If you are running X Clients locally, they still use this variable. You can set it with this command:
Make sure /usr/X11R6/bin is in your $PATH.
Check for underlying system problems or network problems that could be causing problems with the X Window System.
Check the X Font Server for problems described earlier in this chapter.
Even if your X Server is not responding or you can't read the display, don't forget that you can switch to a text console to gain access to the system.
If you are troubleshooting X Server problems on a remote system, try starting an X Client from your workstation using the remote X Server's display. Note that you will need appropriate X security access to run the following command:
# xclock -display remotesys:0.0
Exercise 6-5: Troubleshooting DISPLAY Problems
In this exercise, we will see what happens if you unset the DISPLAY variable.
Log into an X Window session. Run the startx command if required to do so.
Bring up a terminal window. Right-click on the desktop and click New Terminal from the menu that appears.
Start the xclock X Client using the following command:
# xclock &
Unset your DISPLAY variable:
# unset DISPLAY
Start another xclock:
# xclock &
You should get an error message saying that the X Client can't find your display. Reset the DISPLAY variable with the command:
# export DISPLAY=localhost:0.0
Try starting the xclock X Client again.
|< Day Day Up >|| |