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.
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).
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.
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.