GNU bug report logs - #18736
chroot regression - chroot avoids the chroot() call too eagerly.

Previous Next

Package: coreutils;

Reported by: Rogier <rogier777 <at> gmail.com>

Date: Wed, 15 Oct 2014 15:44:04 UTC

Severity: normal

Done: Pádraig Brady <P <at> draigBrady.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Pádraig Brady <P <at> draigBrady.com>
To: Rogier <rogier777 <at> gmail.com>
Cc: 18736 <at> debbugs.gnu.org
Subject: bug#18736: chroot regression - chroot avoids the chroot() call too eagerly.
Date: Wed, 15 Oct 2014 18:17:12 +0100
[Message part 1 (text/plain, inline)]
On 10/15/2014 10:40 AM, Rogier wrote:
> Hi,
> 
> Since a few months, it seems that chroot has started avoiding the 
> chroot call if it can be determined to be idempotent. 
> It looks like the new check is based on inode comparison - if the 
> inode is the same, the chroot() call is considered idempotent, and not 
> performed.
> 
> However, while two directories being in the same file system and having 
> the same inode number implies that they are the same directory, it 
> does not necessarily imply that they have same file system path (i.e. 
> use the same mountpoint), so there is no guarantee that the entire 
> directory trees rooted at the two directories are also identical even 
> though the directories are.This means that chroot will fail to 
> chroot() in cases when the call would in fact not be idempotent.
> 
> On my system (debian testing), I have / bind-mounted elsewhere, with a 
> slightly different directory tree mounted beneath it, as is mounted 
> beneath /. In my case, I need this so that I can make partial backups 
> of the system - including some file systems but leaving out others. 
> Undoubtly, there are other use-cases as well - I wouldn't be surprised 
> if users of libpam-chroot can be affected by this, depending on exactly 
> how they configure their chroot environments.
> 
> The new chroot behavior no longer allows chrooting into such alternate 
> trees. In my case, that means that my backup fails.

I didn't consider this unusual case when avoiding the chroot() call,
for efficiency (especially in the --userspec case), and to add
consistency between platforms in the handling of `chroot / true`
for non root users.

I agree with your analysis and that we should revert
to the previous behavior here, which is done in
the attached patch.

thanks!
Pádraig.
[chroot-always.patch (text/x-patch, attachment)]

This bug report was last modified 10 years and 276 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.