Re: Non-root chroot

From: Vadim Goncharov <vadimnuclight_at_gmail.com>
Date: Fri, 01 Aug 2025 12:55:36 UTC
On Fri, 1 Aug 2025 07:19:36 -0500
Jason Bacon <bacon4000@gmail.com> wrote:

> I'm wondering if there is any way to perform a simple chroot without 
> having root privileges.  The goal is to test software builds with access 
> to a limited set of dependencies, as poudriere does, but outside the 
> FreeBSD ports system, and in some cases on hosts where the user has no 
> root access.  This will prevent configure scripts with hard-coded search 
> paths from finding things we don't want them to find.  Portability to 
> other POSIX platforms would be desirable as well, but is not essential.
> 
> It's not clear to me why chroot() wasn't designed to support this use 
> case.  There's lots of documentation stating that it's a security risk, 
> but I don't see why it couldn't have been designed to be run by a 
> regular user without escalating privileges inside the chroot.  I.e. if 
> user "joe" does such a user-level chroot call, then all chrooted 
> processes run as "joe", but with the path of the chroot dir prepended to 
> every open() call (after $CWD is prepended to relative paths, of 
> course), so that processes can only access files in the chroot dir. 
> User "joe" would have the same privileges inside the chroot that he has 
> on the host. One of the other security concerns mentioned is jail 
> breaks, but if joe managed to escape the chroot, he'd only be hurting 
> himself by borking the test build, so that's not a concern here.
> 
> It might be possible to port fakechroot 
> (https://github.com/dex4er/fakechroot), proot 
> (https://github.com/proot-me/proot), or something similar, but is there 
> anything else on FreeBSD that can do this?

What you want is called jail(8) and it was designed quarter of century
ago exactly to overcome chroot() problems:
https://papers.freebsd.org/2000/phk-jails/
(because one cannot just fix chroot)

Nowadays, there are many jail wrappers so your task of same user
unpriviliged user inside is highly likely solved already.

-- 
WBR, @nuclight