__          __             __
\ \_________\ \____________\ \___
 \  _ \  _\ _  \  _\ __ \ __\   /
  \___/\__/\__/ \_\ \___/\__/\_\_\

Bedrock Linux 1.0alpha3 Bosco

Bedrock Linux 1.0alpha3 "Bosco"

This page was intended to describe plans for the then-upcoming release of Bedrock Linux, 1.0alpha3 "Bosco". Bosco has since been released on 2012/12/25. The following is thus out-of-date, but is kept in case anyone is curious.

Momo's design

The current release of Bedrock Linux, 1.0alpha2 "Momo", allows each chroot'd command to access the other clients via chroots. Before it runs a command from a client - in a chroot - the relevant mount points (/proc, /sys, /home, etc) in that chroot need to be set up. The executables inside of the chroot cannot see outside of the chroot, and so for it to run a command from another client the chroot needs to see all of the files in the other client. To go from one chrooted client into another client, the new chroot/client needs to have its mount points set up as well. This ends up creating a tree representing the client history of every command, and every node on the tree must be set up.

Below you will find is a simple unicode art diagram to demonstrate this concept. If the user were to log in to Bedrock, run a shell from Debian, then run Arch's xorg, then run Debian's xterm within Arch's xorg, the top most branch of the tree below would be followed. Note that mounts such as /proc and /home must each be set up about fourty times in the example below.

Bedrock
  ↳ Arch
  |  ↳ Arch
  |  |   ↳ Arch
  |  |   ↳ Debian
  |  |   ↳ Bedrock
  |  ↳ Debian
  |  |   ↳ Arch
  |  |   ↳ Debian
  |  |   ↳ Bedrock
  |  ↳ Bedrock
  |      ↳ Arch
  |      ↳ Debian
  |      ↳ Bedrock
  ↳ Debian
  |  ↳ Arch
  |  |   ↳ Arch
  |  |   ↳ Debian
  |  |   ↳ Bedrock
  |  ↳ Debian
  |  |   ↳ Arch
  |  |   ↳ Debian
  |  |   ↳ Bedrock
  |  ↳ Bedrock
  |      ↳ Arch
  |      ↳ Debian
  |      ↳ Bedrock
  ↳ Bedrock
     ↳ Arch
     |   ↳ Arch
     |   ↳ Debian
     |   ↳ Bedrock
     ↳ Debian
     |   ↳ Arch
     |   ↳ Debian
     |   ↳ Bedrock
     ↳ Bedrock
         ↳ Arch
         ↳ Debian
         ↳ Bedrock

Real-world use of Momo can easily result in hundreds of thousands of mount points. Since it is not possible to predict how deep the tree will go, Momo cannot set up all of these mounts at boot. Rather, it attempts to create these mounts just before they are necessary on-the-fly. This has a number of down sides:

Bosco's design

The current plan for Bosco is to completely abandon this tree structure in favor of a much flatter layout, which should fix all of the issues listed above. Rather that make the files from other clients accessible from within any given chrooted client, Bosco will allow clients to break out of the chroot (and then go back into another chroot) when trying to run a command from another client. The unicode art tree above will look like this with Bosco:

Bedrock
  ↳ Debian ↰   ↰
  ↳ Arch   ↲ ↰ |
  ↳ Bedrock  ↲ ↲

The number of times each client's mounts have to be set up is constant irrelevant of the history of the commands. All of the mounts could be created at boot, and new mounts could easily be done if a new client is added to a system live. This completely resolves the first three issues with Momo described above and could potentially assist with the fourth.

Bosco's Implementation

brc and capchroot will be replaced by a C program (which will likely take brc's name). This program will be called whenever a user wishes to run a command from other client. This program will do the following:

  1. Determine (a) which command from (b) which client is desired to be run. This might be done in a similar style to how busybox works - it will detect what is desired based on how it is called.
  2. If it is currently in a chroot, break out of the chroot.
  3. Chroot into the client with the desired program
  4. Execute the desired command, passing along all of the arguments. Rather than running the command as a child process, it might replace itself with the command, akin to the Bourne shell's exec.

This command will require two things which typically requires root (using chroot and breaking out of a chroot). If possible, rather than being completely setuid'd, the command will use Linux capabilities (similar to capchroot). Moreover, it will make several checks to ensure it avoids security issues:

Rather than having the BRPATH contain many small scripts which call brc, it will be structured such that a sub-directory for every client which contain symlinks (with the name of the executable desired to be run) which point the new brc. brc will detect how it was called and run the desired command accordingly. For example:

/usr/local/brbin/arch/startx     → /opt/bedrock/bin/brc
/usr/local/brbin/bedrock/busybox → /opt/bedrock/bin/brc
/usr/local/brsbin/debian/gparted → /opt/bedrock/bin/brc

brp will create this structure, just as it created the equivalent structure in Momo.