Package: coreutils Version: 8.23-2 Severity: normal Dear Maintainer,
Some time ago, the chroot command was optimized to avoid the chroot() call if it would be idempotent: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=99960eeab9bf7fb479ab9f5342fc12a1fae629e6 http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=0c4729516baa2fbefb0af66c38f434b1f7519078 While this seems sensible, the current code is too eager, and does not take the mount point of the filesystems into account. This means that currently, chroot can fail to chroot() in cases where it should. In my case, I have '/' bind-mounted elsewhere, with a slightly different set of mounts beneath. While one would expect to be able to chroot into such a tree, the current chroot command fails to do so, as the current root and the new root have the same inode number. I have submitted a coreutils bug report: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18736 Note that besides this bug, only when skipping the chroot() call, the current debian version of coreutils (8.23-2) also does not call chdir("/"), which may violate the assumption in scripts that the working directory is the root directory after invoking 'chroot /'. E.g.: Previously: # pwd /some/path/on/the/system # chroot / # pwd / Current version: # pwd /some/path/on/the/system # chroot / # pwd /some/path/on/the/system Kind regards, Rogier. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (x86_64) Kernel: Linux 3.16-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages coreutils depends on: ii libacl1 2.2.52-2 ii libattr1 1:2.4.47-2 ii libc6 2.19-11 ii libselinux1 2.3-2 coreutils recommends no packages. coreutils suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
