Package: busybox
Version: 1:1.17.1-4
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch maverick
$ sudo busybox sh
BusyBox v1.17.1 (Debian 1:1.17.1-4) built-in shell (ash)
Enter 'help' for a list of built-in commands.
/home/cjwatson # chroot / rm --help
BusyBox v1.17.1 (Debian 1:1.17.1-4) multi-call binary.
Usage: rm [OPTIONS] FILE...
Remove (unlink) FILEs
Options:
-i Always prompt before removing
-f Never prompt
-R,-r Recurse
This is very seriously contrary to how I expect chroot to work. It
should be executing binaries in the selected root filesystem, not
executing busybox applets! (And no, it has nothing to do with chrooting
to / - that's just an example which doesn't require any effort to
construct.)
In Ubuntu, this caused difficult-to-track-down segmentation faults in a
few places, which is how I noticed:
https://bugs.launchpad.net/bugs/594162
https://bugs.launchpad.net/bugs/651046
The attached patch fixes this.
Thanks,
--
Colin Watson [cjwat...@ubuntu.com]
* Never execute busybox applets when chrooting (LP: #594162).
Index: debian/patches/applets-fallback.patch
===================================================================
--- debian/patches/applets-fallback.patch (revision 64892)
+++ debian/patches/applets-fallback.patch (working copy)
@@ -184,3 +184,14 @@
# These are auto-selected by other options
+--- a/coreutils/chroot.c
++++ b/coreutils/chroot.c
+@@ -30,5 +30,7 @@
+ argv[1] = (char *) "-i";
+ }
+
+- BB_EXECVP_or_die(argv);
++ execvp(argv[0], argv);
++ xfunc_error_retval = (errno == ENOENT) ? 127 : 126;
++ bb_perror_msg_and_die("can't execute '%s'", argv[0]);
+ }
