[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#599101: busybox: execs applets when chrooting

Package: busybox
Version: 1:1.17.1-4
Severity: important
Tags: patch
User: ubuntu-devel@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
          -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

In Ubuntu, this caused difficult-to-track-down segmentation faults in a
few places, which is how I noticed:


The attached patch fixes this.


Colin Watson                                       [cjwatson@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]);
+ }

Reply to: