opkg - adding an offline-path option

Werner Almesberger werner at openmoko.org
Mon Nov 24 09:36:35 CET 2008


Christopher Hall wrote:
> Here is a diff to add a simple way to pass a path environment for
> pre/post scription execution when in offline mode.

By the way, when I saw your comment about fakeroot, I checked how
well I was doing with my "sandbox" in myroot, which uses the same
approach: it seems that my host's /etc survived relatively unscathed.
Only /etc/shells had received a few new entries.

However, I wonder if we couldn't make the sandbox a little stronger,
so that the occasional "bad" script someone might add to the
repository doesn't cause devastation. Here's the beginning of an idea:

- ideally, everything would run under chroot, so that nothing bad can
  happen to the host's rootfs

- for executables and libraries, we thus have two choices: 1) run
  them in some ARM emulator, or 2) run native versions instead

- 1) may have a high setup cost, so I'd leave that aside for now.

  There is the possibility to use executable handlers for "foreign"
  formats and I know that some sandboxes are using this (for
  environments that are more ambitious than just running a few
  postinstall scripts), so the whole idea may be worth coming back
  to.

- 2) raises the questions of a) how we get these things into the
  chroot environment, and b) how we make sure they actually get
  used

- for a), we could i) use something other than chroot, such as the
  current PATH-based method, or maybe something that monitors and
  changes paths in library or system calls, ii) just temporarily
  copy all the native things we need into the rootfs, iii) use a
  bind mount, or iv) cook up some new scheme

- i) is the risky approach, avoiding which we're exploring here

- ii) copying everything is safe and simple, but it means that we
  need to identify all the files that could be needed by postinstall
  scripts, or we'd have to just copy everything, which seems a
  little excessive. E.g., on my workstation, just a dumb recursive
  copy of {,/usr}/{bin,lib} would amount to about 2GB of data.

- iii) bind mounts are more elegant, but they have the drawback that
  they don't prevent writes if the original isn't read-only. This
  problem could be mitigated by mounting things at a place the
  postinstall scripts aren't likely to visit. (I hope none are doing
  a find / ...)

- iv) a new scheme could be in the form of exec/open being
  intercepted and file handles from the rootfs being obtained via
  file descriptor passing

- regarding b), the issue takes the form of what happens on
  x) regular executable invocation at the system call level, i.e.,
  execve("/bin/foo", ...), y) the same at the library level using
  PATH, i.e., execlp("foo", ...), which involves a search for the
  executable with "stat", and of course z) access to shared
  libraries, which is "open" followed by "mmap".

- since we're in a strong sandbox (chroot), we can afford to be
  wrong sometimes. E.g., if we end up running something from the
  "wrong" world, we're probably okay more often than not.

- so we'd basically want to have two roots: one for executables and
  libraries, and one for all the rest

- a really easy solution for x) through z) would be to just put the
  host's executables and libraries at the place where the ARM ones
  live, moving the latter to a backup location in case of conflicts.

  This may work with approach ii), since even changes made by the
  postinstall scripts to /bin and the like would survive the cleanup.
  It would not work very well for iii), since we'd end up writing to
  the host's directories.

- with iii), we would have to mount the host directories out of
  harm's way, while still making sure things still get picked up from
  there. y) is easily solved with a PATH that goes to the bind mounts
  first. For z), LD_LIBRARY_PATH might accomplish the same. This
  leaves x), which would need a library or system call redirecter,
  i.e., through LD_PRELOAD or ptrace.

So if my assumptions are correct, iii) with a little helper that
changes the path in execve calls looks quite nice. I wonder if
anyone has done something like this already ?

- Werner



More information about the devel mailing list