10. Advanced X Usage

There's a lot to learn about X, a lot of info buried in the inscrutible land of man pages, a lot of things most folks don't bother reading. Some if it is rather important, and it's easy to make some mistakes, and get completely stuck. It can be much harder to build a program in X, or check the security of X, or many other things, because X and all the things that run on top of it are so vast. This section is an attempt to cover some of the more advanced and confusing situations that may arise.

10.1 Libraries and Compiling X Applications

Sooner or later you will have to deal with compiling applications of your own. Later, if you just installed a nice distribution of linux, and are happy with what you've got, sooner, if you're the kind of person who likes to tinker and install. Remember, this is a privilege, not a right, so have fun with it!

First, a few pointers on compiling programs with X. Many newer applications, GNU applictions in particular, come with a script in the root directory called configure. This assumes of course that you've extracted the file and are in the directory. This program should be run as ./configure, and will automatically detect many things about your system. Afterwards, simply running make and perhaps becoming root and running make install will get the program up on your system.

You may have to do a little more tinkering if you do not have a configure script available. Many X programs require you to run a program to make the Makefile, called xmkmf. If you don't see a Makefile in your directory, this will sometimes work, and will generate a suitable configuration for you, and you'll be ready to make from there.

Sometimes you will have run the configure script, and have been warned that you lack a library that would be helpful or necessary to properly use that application. For instance, I recently installed the xscreensaver application, and found that it would support several 3D modes if the Mesa library was installed. If you run into this situation and want that library installed, the first thing you should do is check the CD or installation media for your Linux distribution to see if you have the library on there. That may save you lots of trouble trying to compile the library.

Once you get a library compiled and installed and ready to use, you can go back to the directory you were installing your X program from, remove the config.cache file, and run the configure script again. Hopefully it will find the library you have installed. Sometimes it does not, and you have to tinker to get it working. This happens occasionally with libraries you download off the net, that do not adequately support the Linux File System Standard (most do, however).

10.2 Basic X Security

It has often been said that X has a very simple security model: All or Nothing. This is not much of an exaggeration at all. X can be configured to use somewhat sophisticated security, via encryption, but that is beyond the scope of this HOWTO (for the present). It is assumed that the user is not using any encryption for this discussion.

First of all, you should try and follow some simple rules when you're compiling programs for X (or for any reason, really). Try not to become root any more than necessary. Configure your programs as a normal user with the ./configure && make (or just make if there's no configure script), and then issue the single command to install it as root by typing su -c "make install", and then typing in the root password at the prompt. That way you won't have to be logged in as root, you can just issue a single command, and you're back to your normal user prompt. This is a smart, safe way to install software.

The next thing to think about is running X software as root. Realize that X is more or less inherently insecure, and if your primary concern for a particular Linux box is security, you really don't want to install X at all! Having said that, some folks want to run nice fancy configuration programs or package management tools in X. I do not recommend starting X as root. It's just not a good idea. There's much, much better ways to do these things!

If you want to run an X application as root, just log in under your normal user account, and launch it from there. As I mentioned above, you don't want to be logged in as root any more than absolutely necessary. The root user has the ability to do just about anything on the system, including about a million ways to destroy it completely. Simply go to your xterm or such application and type in a command such as su -c "glint -display :0.0" to launch the window on your desktop. Now you have a single window running as root, and not the whole desktop. You might also want to consider using the complete pathname to the program you're running as root, for extra security.

Tomasz Motylewski also offers the following tip for ssh and ssh-agent lovers. If you put the following in your /usr/X11R6/lib/xinit/Xclients file:

 eval "exec ssh-agent fvwm${FVWMVER} ${FVWMOPTIONS}" >
 "$HOME"/.FVWM${FVWMVER}-errors 2>&
 

That is, replace your standard fvwm${FVWMVER} ${FVWMOPTIONS} command with the preceeding. That is to start your window manager as a child of ssh-agent. Then you should try ssh-add < /dev/null from an xterm session (if you have your identity RSA key in the file  /.ssh/identity). If this works for you then you should find that you are authenticated in all your X windows.

It should be noted that this is a suggestion from the reader, and the author has no experience with ssh at the present, so proceed at your own risk! More recent Linux distributions allow for setting up ssh automatically, via setup or something similar, which means that you may not have to worry too much about setting it up, just understanding how it works.

10.3 More About X Authority

The mysteries of user authentication in X are a prime example of the security problems many users encounter with X. Tomasz Motylewski relates the following story, which sums up the situation quite well.

``...in the default XFree86 configuration X session started by ``startx'' accepts commands from everyone connecting from localhost. If you start X as user1 and you have user2 remotely logged in, user2 has full access to your keyboard and desktop (once my friend played a joke on me and put in his cron commands dumping my X desktop image and sending to him every hour). I did not notice it for 2 weeks!''

Well that's not exactly a good thing, but unfortunately many readers have this exact problem. Tomasz goes on to point out that if you use xdm to log in (as detailed earlier in this HOWTO), rather than just running startx, this won't be a problem because access is controlled by the xauth program. By issuing the xhost command, you can see who is allowed access to your X session. Any user from the hosts that are listed in the output of the xhost command is authorized full access to your screen and keyboard.

If you want to start your X server in a secure fashion from the command line, you will need to make the following modifications to your configuration. First, modify startx (probably at /usr/X11R6/bin/startx) by changing the last line xinit $clientargs -- $serverargs to read exec xinit $clientargs -- $serverargs -auth ~/.Xauthority.

Then you will also need to edit your .xinitrc or your system-wide /usr/X11R6/lib/xinit/xinitrc (whichever you are actually using, probably the one in your home directory), by adding this at the beginning of the file:

 # if Xserver has been run with "-auth ~/.Xauthority" option
this will
 # prevent other users on your machine to connect to your X server
 # unless you allow it explicitly using xhost +host or give them
 # your ~/.Xauthority file.
 xauth generate $DISPLAY . trusted
 

Always be sure and run xhost to check the security that you have configured, to make sure everything is working correctly.