[colug-432] bedrock linux: how's it work? Re: November COLUG Meeting Announcement

[Daniel Thau]

On Fri, Nov 21, 2014 at 03:12:43AM -0500, Jeff Frontz wrote:
> Is there any place that gives a description of how bedrock linux works?
> I've read what the benefits are, why you'd use it, etc., but what exactly
> is going on under the covers?  After some googling, I saw some hint on
> slashdot and elsewhere that chroot and bind-mounting are employed -- but
> what else? Modifications to exec* (and other?) system calls?
> 
> Thanks,
> Jeff
> 

How Bedrock Linux works changes substantially between releases.  I
essentially gave up trying to maintain any up-to-date documentation on
how it works at a low level.  I'd rather spend the time working on the
still unfinished project.  I fully intend to document it in detail once
it hits 1.0 stable, at which time the regular churn will have
dissipated.

The hardest part of answering a question such as yours is that there is
a lot that Bedrock Linux has to do - there isn't just one thing to hook
into and have everything work that I could explain and be done with it.

While the specific details have changed since the over two year old
slashdot article, chroot() and bind-mounts are still used, as are shared
subtrees, pivot_root() (in the next release), multiple FUSE filesystems,
capabilities, various toying with $PATH-style variables, hooking into
the startup routines for login shells (e.g. /etc/profile), (ab)using
obscure nuances of how Linux implements things such as relative
filesystem path resolution.  I'm probably forgetting other things - that
was just off the top of my head.  Any and all of those may end up being
dropped later as the strategy evolves.  There's also experimentation
with other things for possibly inclusion in future releases, such as
on-the-fly alteration of binary executables.

Bedrock Linux does not modify any system calls.  This is for two
reasons:

- Bedrock Linux lets the user get as much as is possible from other
  distros (or compile themselves).  This includes kernels.  I can't
  predict what crazy kernel an end-user will want - maybe they've
  already done something weird to exec().  There's potential conflicts
  there that would be best avoided.  Bedrock Linux does impose some
  requirements on the kernel - e.g. FUSE support - but they're all very
  common.  The only problem I've run into is grsec "securing" away
  aspects of chroot() that Bedrock Linux relies on.  Outside of that I
  want to impose as little as possible.  Let the user get their kernel
  from whatever obscure distro they want, or build it however they
  please.

- It would require recompiling kernel modules every kernel change which
  would be non-trivial to implement in an automated fashion (given
  nuances of how Bedrock Linux works), and a giant pain if required to
  be done manually.

Linux's hooks from the userland are surprisingly flexible and, thus far,
have been sufficient to get the job done.  There's been discussion of
branching off another approach utilizing modules but I'm doubtful it
will be seriously pursued until 1.0 is done.

In general, if someone is very serious about potentially contributing to
a complicated part of the system, I'll be happy to take the time to walk
them through how it works.  Otherwise, the choices largely boil down to
some combination of using the system and poking around, walking through
the code base to figure it out, following development discussions by
idling in the IRC room (especially during the monthly developer
meetings), or waiting until the planned write-up that should occur once
the churn dies down.

Daniel "paradigm" Thau
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
Url : http://lists.colug.net/pipermail/colug-432/attachments/20141122/85d61cad/attachment.bin