[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: FTBFS when /bin is before /usr/bin in PATH?



* Simon Josefsson <simon@josefsson.org> [250506 11:35]:
I'm doing archive-wide package rebuilds in GitLab CI/CD and my toolchain
uses 'setpriv --reset-env' to drop privileges and reset the environment
variables, which results in:

PATH=/usr/local/bin:/bin:/usr/bin

This unusual ordering appears to be intentional for setpriv:

https://manpages.debian.org/bookworm/util-linux/setpriv.1.en.html

However this ordering is different than the PATH used on buildd's:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

Having /bin before /usr/bin cause FTBFS of some packages.  The most
simple example is packages that invoke gradle.  It appears to happen
both on bookworm and trixie, and is easy to reproduce:

podman run -it --rm debian:trixie
apt-get update
apt-get install -y --no-install-recommends gradle
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
gradle
/bin/gradle: 23: cd: can't cd to /bin/../share/gradle/bin/..

I'll point out that this is not even trying to build a Debian package, so the typical Debian package build environment would be irrelevant here.

The problem seems that it is generating a relative path to its own
command expanded via PATH, which doesn't work because there is no /share
symlink but there is /usr/share/.

Is this a problem in 'gradle' (and other packages) that should be
reported and fixed?
IMO yes, see below.

What severity?

normal?

What can packages assume about PATH?  What can packages not assume?  In
particular wrt ordering.  Are there written down rules for this?

Probably in POSIX. Per my understanding PATH is defined to be used in a specific algorithm, which is basically "stat the name of the executable you are looking for in these directories, in the given order". Everything else is probably unspecified, and deriving file system paths that are not actually given in PATH is undefined behaviour, and can just break.

If a program needs to know a path to supporting files, this path should be known at build time of that program (here: gradle), and then be baked into it (and maybe also be configurable at runtime).

Chris


Reply to: