find_paths does not work inside chroot.

Description

The find_paths command (and probably the API as a whole) does not work properly when inside a chroot.

The following command was found in mev build system:
findpaths -r "makefile_engine" B_FIND_PATH_DEVELOP_DIRECTORY

When used inside an haikuporter chroot, it will only work if there is a makefile_engine package installed outside the chroot, in the real /system directory. It is expected that it would look for package mount points inside the chroot, instead.

Change History (7)

Moving to beta1: this error prevents setting up build slaves with mmlr tools.

In this configuration, the build slave does not use the packages from /system at all, instead, a separate local package repository is used. This allows running an old version of Haiku, but building packages for a newer one, and vice versa. So, the buildslaves' system can be left at a single "stable" version, then they can be used to build packages targetting any other version of Haiku.

However, findpaths -r uses package information from the "real" /boot/system, somehow escaping the chroot. So, it will try to find the makefile_engine package (for example) using the hrev from the real /system, in the repo populated in the package building chroot (confirmed by stracing the call to findpaths).

findpaths -r needs to first find the requested package. It does so by querying the package roster for all installed packages. This is implemented through BDaemonClient::GetInstallationLocationInfo, which asks the package daemon.

The problem is, the package daemon lives outside the chroot and has no idea about it. So, it will return the main system packages directories instead of the ones in the chroot. Moreover, it returns a device+node pair, which the package kit can use to "escape" the chroot and list packages outside of it. So we end up with the list of packages from the system, which is the cause for the bug here and also a security problem.