bug#18736: chroot regression - chroot avoids the chroot() call too eagerly.

[Pádraig Brady]

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
Description: Text Data