qemu: findQemuDataDir returns uncanonicalized relative paths for symlinks

[slash-init]

Problem Description

In pkg/unikontainers/utils.go, findQemuDataDir() checks whether /usr/local/share/<name> is a symbolic link. When it is, the function uses os.Readlink() and directly returns the symlink target.
os.Readlink() returns the target exactly as stored in the symlink. If the target is relative, the returned value is therefore also relative to the symlink's parent directory rather than an absolute path.
For example, if:

/usr/local/share/qemu -> ../share/qemu

then os.Readlink("/usr/local/share/qemu") returns:

../share/qemu

findQemuDataDir() currently returns that value without resolving it relative to /usr/local/share/.
The returned path is subsequently used by mountsForMonitor() in pkg/unikontainers/rootfs.go as the source of a bind mount:

mounts = append(mounts, bindMount(qDataPath, "/usr/share/qemu", true, true))

The relative path can then be interpreted relative to the process's current working directory rather than the directory containing the symlink. This can cause the subsequent filesystem or mount operation to fail with ENOENT.

Affected Code

File: pkg/unikontainers/utils.go

func findQemuDataDir(basename string) (string, error) {
	// First check if the file exists under /usr/local/share
	qdPath := filepath.Join("/usr/local/share/", basename)
	info, err := os.Lstat(qdPath)
	if err != nil {
		if !os.IsNotExist(err) {
			return "", fmt.Errorf("failed to get info of %s: %w", qdPath, err)
		}
		// The file does not exist under /usr/local/share
		// fallback to the usual path /usr/share/
		qdPath = filepath.Join("/usr/share/", basename)
	} else {
		// The file exists under /usr/local/share, but check if it is a link
		if info.Mode()&os.ModeSymlink != 0 {
			// It is a link, get the target
			qdPath, err = os.Readlink(qdPath)
			if err != nil {
				return "", fmt.Errorf("failed to get target of %s %w", qdPath, err)
			}
		}

		return qdPath, nil
	}

	return qdPath, nil
}

The issue is specifically the os.Readlink() path: the returned target is not resolved relative to /usr/local/share/<name> before being returned.

Failure Scenarios

1. Relative symlink target

Given:

/usr/local/share/qemu -> ../share/qemu

findQemuDataDir("qemu") returns:

../share/qemu

instead of the path represented by the symlink.
When this value is later used as a filesystem path, its interpretation depends on the process's current working directory.

2. Chained symlinks

os.Readlink() resolves only the first symlink itself. If the target is another symlink, findQemuDataDir() does not resolve the remaining chain.

3. Broken symlink

os.Lstat() succeeds for a dangling symlink because the link itself exists. os.Readlink() also succeeds and returns its target.
As a result, the function does not detect that the target is missing and does not fall back to /usr/share/<name>.

Expected Behavior

findQemuDataDir() should return a path that correctly represents the target of a symlink under /usr/local/share/, independent of the process's current working directory.
Symlink resolution should also correctly handle chained symlinks and detect a broken target so that the existing /usr/share/<name> fallback can be used where appropriate.

Impact

On systems where the QEMU data directory under /usr/local/share/ is represented by a relative symlink, the current behavior can result in an invalid source path being passed to the monitor filesystem setup.
This can prevent the container/unikernel from being created even though the expected QEMU data directory exists and is reachable through the symlink.

[cmainas]

Hello @slash-init ,

can you provide steps to reproduce this issue?

[slash-init]

Hello! @cmainas
The issue can be reproduced with the following steps:

1. Create a relative symlink where /usr/local/share/qemu points to /usr/share/qemu:

mkdir -p /tmp/repro/usr/local/share
mkdir -p /tmp/repro/usr/share/qemu

ln -s ../../share/qemu /tmp/repro/usr/local/share/qemu

2. Verify that the symlink is relative and resolves to the expected directory:

readlink /tmp/repro/usr/local/share/qemu
# ../../share/qemu

realpath /tmp/repro/usr/local/share/qemu
# /tmp/repro/usr/share/qemu

3. The current findQemuDataDir() implementation uses os.Readlink() when it encounters the symlink. A minimal reproduction of that logic:

qdPath := "/tmp/repro/usr/local/share/qemu"

info, _ := os.Lstat(qdPath)
if info.Mode()&os.ModeSymlink != 0 {
    qdPath, _ = os.Readlink(qdPath)
}

fmt.Printf("%q\n", qdPath)

This prints:

"../../share/qemu"

while the actual resolved path is:

"/tmp/repro/usr/share/qemu"

So the issue is that findQemuDataDir() returns the raw relative target from os.Readlink() instead of resolving it relative to the symlink's parent directory.

[cmainas]

Hello @slash-init ,

I meant end-to-end showing the execution failure in urunc.

[slash-init]

Hi @cmainas
Yes, I traced the call path and reproduced it end-to-end through urunc itself.

Reproduction

Run this from the urunc repository root:

docker run --rm \
  --privileged \
  --security-opt seccomp=unconfined \
  -v "$PWD":/src:ro \
  -w /src \
  golang:1.26-bookworm \
  bash -euxo pipefail -c '
    apt-get update >/dev/null
    apt-get install -y --no-install-recommends qemu-system-x86 >/dev/null

    go build -buildvcs=false -o /tmp/urunc ./cmd/urunc

    rm -rf /work /share /usr/local/share/qemu /usr/local/share/seabios /tmp/urunc-state
    mkdir -p /work/bundle/rootfs /usr/local/share /usr/share/seabios

    cp "$(command -v qemu-system-x86_64)" /work/qemu-system-x86_64
    printf x >/work/bundle/rootfs/kernel

    # Relative symlink: this resolves to /usr/share/qemu.
    ln -s ../../share/qemu /usr/local/share/qemu

    rm -f /dev/kvm
    mknod /dev/kvm c 10 232

    printf "%s\n" \
      "[runtime]" \
      "libcontainer = false" \
      "[monitors.qemu]" \
      "path = \"/work/qemu-system-x86_64\"" \
      >/tmp/urunc.toml

    printf "%s\n" \
      "{" \
      "  \"ociVersion\": \"1.0.2\"," \
      "  \"process\": {\"terminal\": false, \"args\": [\"/kernel\"], \"cwd\": \"/\", \"user\": {\"uid\": 0, \"gid\": 0}}," \
      "  \"root\": {\"path\": \"rootfs\"}," \
      "  \"linux\": {\"namespaces\": [{\"type\": \"mount\"}]}," \
      "  \"annotations\": {" \
      "    \"com.urunc.unikernel.unikernelType\": \"linux\"," \
      "    \"com.urunc.unikernel.hypervisor\": \"qemu\"," \
      "    \"com.urunc.unikernel.binary\": \"/kernel\"" \
      "  }" \
      "}" \
      >/work/bundle/config.json

    cd /work

    URUNC_CONFIG_FILE=/tmp/urunc.toml \
      /tmp/urunc --debug --root /tmp/urunc-state \
      create -b /work/bundle repro

    URUNC_CONFIG_FILE=/tmp/urunc.toml \
      /tmp/urunc --debug --root /tmp/urunc-state \
      start repro
  '

The command exits with a non-zero status. The relevant failure is:

failed to apply mount ../../share/qemu:
failed to create mount target /work/bundle/monRootfs/usr/share/qemu:
failed to stat mount source ../../share/qemu:
no such file or directory

This happens because findQemuDataDir("qemu") encounters:

/usr/local/share/qemu -> ../../share/qemu

and uses os.Readlink(), which returns the raw relative target:

../../share/qemu

instead of resolving it to:

/usr/share/qemu

That value is then persisted as the mount source and later consumed by applyMounts() during urunc start, where the relative path cannot be found.
The repository is mounted read-only and the Docker container is removed automatically, so the reproduction does not modify the host repository or require an existing QEMU installation.

[cmainas]

To be honest this sounds more like a broken host setup. Actually, we should get rid off the soft/hard link discovery and simply fail if we can not find the dat apath. We already have a configuration option for the data path and if users do not configure it correctly it is not the fault of urunc, simply eveyr execution will fial.

[slash-init]

Thanks for the clarification @cmainas , that makes sense.
The repro was mainly to show what happens with the current discovery logic when /usr/local/share/qemu is a relative symlink. But I see your point that the symlink itself isn't necessarily a broken host setup.
Since there's already a config option for the QEMU data path, should findQemuDataDir() just stop trying to discover it under /usr/local/share and /usr/share, and instead rely on the configured path?
If that's the intended direction, I'll rework the issue/patch around that rather than trying to fix the symlink resolution.