Contents
Using X applications in a chroot
To use X applications in a chroot environment
make /home/user in the chroot for your user id. do something like chown user:user /home/user to give it correct permissions.
modify /etc/passwd and /etc/group in the chroot environment to have the same uid as your system ones
Then, on entry to the chroot
bind mount your real home directory to the chroot home directory
bind mount the chroot /tmp to the system /tmp
mount /proc and /sys
call chroot with the su command to switch to your user in the chroot (don't use - as this will destroy important environment variables)!
On exit, unmount the directories just so as to not leave things lying around.
Not Binding
If you set your DISPLAY environment to be simply :0.0 as this will try to use the UNIX socket in /tmp which won't be in your chroot if you don't bind mount the system /tmp
You need your X server capable of listening on the network, which requires turning off -nolisten tcp. If you usually start X via the startx command you can edit out flag in the /etc/X11/xinit/xserverrc, but if you start from gdm you'll need to look at /etc/gdm/gdm.conf and have a look at the DisallowTCP option.
Once you have restarted your X server should be ready to listen for network connections. In your chroot set your DISPLAY variable to be localhost:0 to force the network socket connection.
At this point you need to sort out allowing access, the easy option is to do something like xhost +localhost to allow yourself to connect. Or you can do it properly with magic cookies.
A very handy way of getting things into the chroot environment is to bind mount them. You can do mount --bind olddir newdir to make olddir look just like newdir. This will break through the chroot, which is at times great and at times a security risk. You can make scripts to bind mount in home directories (and even /tmp to avoid the unix socket problem).
Devices
Another problem is that debootstrap seems to not make all the devices required. If you see something like
host:/# xterm xterm: Error 32, errno 2: No such file or directory Reason: get_pty: not enough ptys
try running MAKEDEV pty in /dev to make the devices you need.
Example Script
#/bin/bash #1. bind mount home dir mount --bind /home/user /chroot/home/user mount --bind /tmp /chroot/tmp mount /chroot/sys mount /chroot/proc #2. chroot in and swap user chroot /chroot su user #3. on exit unmount umount /chroot/home/user umount /chroot/tmp umount /chroot/sys umount /chroot/proc
Example /etc/passwd and /etc/user
/etc/passwd
[blah] gdm:!:101:105:Gnome Display Manager:/var/lib/gdm:/bin/false user::1076:1076:mattf:/home/user:/bin/bash
/etc/group
[blah] gdm:x:105: user:x:1076:
Note on being root
Note there is no password in the /etc/passwd file, so using sudo with password authentication isn't going to work. To get around that, use visudo as root in the chroot to initially setup a /etc/sudoers that doesn't require a password
# User privilege specification root ALL=(ALL) ALL user ALL=(ALL) NOPASSWD: ALL
Desktop Environments
KDE and Gnome tend to start a lot of daemons doing different things. If you have both a native version running, and try to run a version in the chroot it will probably not work.
This works best for standalone
Xnest
One fairly nice way to get a remote gnome session with a minimum of fuss is to use Xnest. This just makes a little X server in a window.
Firstly, setup xauth to allow you through
ianw@lime:~$ echo $DISPLAY :0.0 ianw@lime:~$ xauth list localhost.localdomain:0 MIT-MAGIC-COOKIE-1 bd72c2....6c8ab8 lime/unix:0 MIT-MAGIC-COOKIE-1 9a5c6...648d4bffd localhost.localdomain/unix:0 MIT-MAGIC-COOKIE-1 9a5c6b555f...bffd
Copy the cookie that corresponds to your current display to a new one for display :1
ianw@lime:~$ xauth add :1 MIT-MAGIC-COOKIE-1 bd72c2....6c8ab8
Then startup Xnest on display :1
ianw@lime:~$ Xnest -auth .Xauthority :1 &
Then fire up an xterm that ssh's to the remote box and starts up something like gnome-session
ianw@lime:~$ xterm -display :1 -e ssh tutti gnome-session
