[Bug 16273] New: "readlink -f" on a relative symlink is (erroneously) workdir dependent since busybox 1.35

bugzilla at busybox.net bugzilla at busybox.net
Mon Dec 9 22:56:51 UTC 2024


https://bugs.busybox.net/show_bug.cgi?id=16273

            Bug ID: 16273
           Summary: "readlink -f" on a relative symlink is (erroneously)
                    workdir dependent since busybox 1.35
           Product: Busybox
           Version: 1.35.x
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: Other
          Assignee: unassigned at busybox.net
          Reporter: admwiggin+busyboxbugs at gmail.com
                CC: busybox-cvs at busybox.net
  Target Milestone: ---

Setup:

> + mkdir -p /foo /bar /1/2
> + ln -sv ../bar/baz /foo/buzz
> '/foo/buzz' -> '../bar/baz'
> + find /foo /bar -exec ls -ld '{}' +
> drwxr-xr-x    2 root     root          4096 Dec  9 22:41 /bar
> drwxr-xr-x    2 root     root          4096 Dec  9 22:41 /foo
> lrwxrwxrwx    1 root     root            10 Dec  9 22:41 /foo/buzz -> ../bar/baz

With the above directory structure in place, performing `readlink -f /foo/buzz`
with PWD of / works fine.
If PWD is one level deep (`/1`), it also still works fine (and returns
`/bar/baz` as expected).
If PWD is *two* levels deep (`/1/2`), the same `readlink -f /foo/buzz` command
fails.

After bisecting the issue, I found it was introduced by
94eb1c4dc6556932e1a12a0ce7734512ac95985e ("libbb: better coreutils
compatibility for realpath" -- released in BusyBox 1.35.0).
I was able to confirm this by testing on 1.34.1 (where the two-level-deep
readlink works fine) and applying that single commit, after which it fails.

It also still fails on the latest release (1.37.0) and current master (I tested
on 371fe9f71d445d18be28c82a2a6d82115c8af19d, specifically -- "ash: move
hashvar() calls into findvar()" from Jul 13, 2024).

It's not particularly relevant, but as a point of interest this was discovered
(with credit to Tõnis Tiigi and CrazyMax) because Alpine 3.21 was recently
released, and in it, `/var/lock` is now a symlink to `../run/lock` (and was
previously a directory), and `/run` is an empty directory, which matches the
structure of my example reproducer above.

In case it's helpful, here's a `Dockerfile` I've been using for
testing/bisecting this:

> FROM busybox
> RUN mkdir -p /foo /bar && ln -sv ../bar/baz /foo/buzz && find /foo /bar -exec ls -ld {} +
> RUN readlink -f /foo/buzz
> WORKDIR /1/2
> RUN readlink -f /foo/buzz

(I wasn't sure if the "Version" metadata in Bugzilla should be set to the first
version where the problem exhibits or to the most recent version where it still
exhibits so I went with the former but tested all the way to latest master as
noted above.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the busybox-cvs mailing list