Re: Git 2.18: RUNTIME_PREFIX... is it working?

From: Jeff King <peff@peff.net>
Date: Jul 10, 2018, 14:03 UTC
Message-ID: <20180710140310.GA9246@sigill.intra.peff.net>
In-Reply-To: <5b445ca6.TkV9Dj8T2KFinxZP%perryh@pluto.rain.com>

On Tue, Jul 10, 2018 at 12:13:42AM -0700, Perry Hutchison wrote:

Show 12 quoted lines

> Jeff King <peff@peff.net> wrote:
> 
> > If I understand correctly, the Linux implementation requires reading
> > from /proc. So an executable that only did RUNTIME_PREFIX (with no
> > fallback to static paths) would be unhappy inside a chroot or other
> > container that didn't mount /proc.
> 
> If we need /proc, wouldn't we _already_ be unhappy inside a chroot
> that didn't mount /proc, even _with_ fallback to static paths?
> Last I knew, the whole point of chroots/containers/jails/etc. was to
> prevent access, from a process running inside the container, to any
> part of the FS that's outside of the container.

My point is that aside from RUNTIME_PREFIX, we don't need /proc. So somebody who currently builds Git with a static path like "/usr/libexec/git-core" and runs it inside a chroot will be just fine as long as /usr/libexec/git-core is available at that name inside the chroot. But if the build starts relying on RUNTIME_PREFIX, it's going to regress their case.

I'm not sure how hypothetical this is. A lot of Debian tools use chroots to build packages for specific releases by basically installing the distro inside the chroot. I don't know whether /proc is available in those chroots or not. If not, then I suspect builds that rely on installing Git inside the chroot are going to break.

+cc Jonathan, who maintains the Git package for Debian, and can probably say immediately whether I am way off base. ;)

-Peff