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