Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#12602 closed bug (fixed)

find_paths does not work inside chroot.

Reported by: pulkomandy Owned by: pulkomandy
Priority: high Milestone: R1/beta1
Component: Kits/Storage Kit Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All


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.

Attachments (1)

mev_build.log (7.9 KB ) - added by diver 4 years ago.

Download all attachments as: .zip

Change History (7)

by diver, 4 years ago

Attachment: mev_build.log added

comment:1 by pulkomandy, 4 years ago

Milestone: UnscheduledR1/beta1
Priority: normalhigh

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).

comment:2 by pulkomandy, 4 years ago

Investigation progress:

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.

comment:3 by pulkomandy, 4 years ago

Owner: changed from bonefish to pulkomandy
Status: newin-progress

comment:4 by pulkomandy, 4 years ago

Resolution: fixed
Status: in-progressclosed

Fixed in hrev50499.

comment:5 by khallebal, 4 years ago

The link of the fix seems to lead to a commit which has nothing to do with this ticket??

comment:6 by pulkomandy, 4 years ago

This is because that hrev has two (unrelated) commits. The other one is accessible with the "parent" link from cgit:

Note: See TracTickets for help on using tickets.