[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