Difference between revisions of "Development Team/Chroot"

From Sugar Labs
Jump to navigation Jump to search
m
Line 46: Line 46:
  
 
before entering the chroot. (Mock uses unshare() to enter a new mount-point namespace since this makes garbage collection of mountpoints much easier.)
 
before entering the chroot. (Mock uses unshare() to enter a new mount-point namespace since this makes garbage collection of mountpoints much easier.)
 +
 +
=== User Account ===
 +
 +
For stupid reasons, it's necessary that Sugar run under a uid inside the chroot which exists as a real account outside the chroot. (Talk to the DBus people.)
 +
 +
Consequently, run something like this both inside and outside the chroot:
 +
 +
  groupadd -g 64002 sugar
 +
  useradd -m -u 64002 -g sugar sugar
 +
 +
Then, inside the chroot, you can happily run sugar as user 'sugar' with something like
 +
 +
cat > as_person <<EOF
 +
#!/usr/bin/env python
 +
from os import environ, chdir, setgroups, setgid, setuid, execve
 +
from sys import argv
 +
from pwd import getpwnam
 +
user = getpwnam(argv[1])
 +
environ['HOME'] = user.pw_dir
 +
environ['USER'] = user.pw_name
 +
chdir(user.pw_dir)
 +
setgroups([user.pw_gid])
 +
setgid(user.pw_gid)
 +
setuid(user.pw_uid)
 +
execve(argv[2], argv[2:], environ)
 +
EOF
 +
chmod a+x as_person
 +
./as_person sugar /usr/bin/sugar

Revision as of 20:17, 5 January 2009

Sugar ought to be easy to run from chroots. For a variety of silly reasons, this isn't yet the case, but it might be soon. Ping Michael with questions.

Chroot Construction

There are lots of ways to create appropriate chroots; e.g. by hand, with debootstrap, with mock, etc.

With debootstrap, in order to get a working chroot, you want something like:

 export CHROOT=`pwd`/sid-root
 debootstrap --arch i386 sid $CHROOT http://debian.lcs.mit.edu/debian
 sudo chroot $CHROOT /bin/bash -l
 # and some of the following:
 mount -t proc proc $CHROOT/proc
 mount -t devpts devpts $CHROOT/dev/pts
 mount -t selinuxfs selinux $CHROOT/selinux


With mock, it would be more like:

 mock -r fedora-devel-i386 --init
 mock -r fedora-devel-i386 --shell

X11

Most X11 servers are configured to disable TCP connections. This means that in order to get a working X connection we can:

  1. bind-mount the X unix socket into the chroot.
  2. ssh into the chroot with X11-forwarding enabled.
  3. enable TCP on an X server, e.g. a nested Xephyr.

We're going to try option (3) first:

 Xephyr -ac :1
NB: If you figure out how to make Xephyr bind only to localhost sockets (or how to make it use a custom xauth config), speak up!

and, inside the chroot:

 export DISPLAY=localhost:1

D-Bus

Sugar wants to be able to use global state stored in both HAL and NetworkManager, both of which live on the system bus. Consequently, we need to bind-mount

 mount --bind /var/run/dbus $CHROOT/var/run/dbus

before entering the chroot. (Mock uses unshare() to enter a new mount-point namespace since this makes garbage collection of mountpoints much easier.)

User Account

For stupid reasons, it's necessary that Sugar run under a uid inside the chroot which exists as a real account outside the chroot. (Talk to the DBus people.)

Consequently, run something like this both inside and outside the chroot:

 groupadd -g 64002 sugar
 useradd -m -u 64002 -g sugar sugar

Then, inside the chroot, you can happily run sugar as user 'sugar' with something like

cat > as_person <<EOF
#!/usr/bin/env python
from os import environ, chdir, setgroups, setgid, setuid, execve
from sys import argv
from pwd import getpwnam
user = getpwnam(argv[1])
environ['HOME'] = user.pw_dir
environ['USER'] = user.pw_name
chdir(user.pw_dir)
setgroups([user.pw_gid])
setgid(user.pw_gid)
setuid(user.pw_uid)
execve(argv[2], argv[2:], environ)
EOF
chmod a+x as_person
./as_person sugar /usr/bin/sugar