[Bug 248184] readlink("/proc/curproc/file") returns arbitrary correct name for programs with more than one link (name)

From: <bugzilla-noreply_at_freebsd.org>
Date: Tue, 19 Oct 2021 13:11:48 UTC

Tobias Kortkamp <tobik@freebsd.org> changed:

           What    |Removed                     |Added
                 CC|                            |tobik@freebsd.org

--- Comment #6 from Tobias Kortkamp <tobik@freebsd.org> ---
(In reply to Conrad Meyer from comment #1)
The problem is also present with AT_EXECPATH.

AT_EXECPATH doesn't really make a difference if the wrong name
is copied to userspace in the first place.

$ freebsd-version
$ cat execpath.c
#include <sys/auxv.h>
#include <limits.h>
#include <stdio.h>

main(int argc, char *argv[])
        char pathname[PATH_MAX];
        elf_aux_info(AT_EXECPATH, pathname, PATH_MAX);
        return 0;
$ make execpath
$ ln -f execpath tmp/execpath
$ ./execpath
$ ./tmp/execpath
$ ./execpath # I'd expect this to return /home/tobias/execpath again but:

Now I'm coming back to this because lang/rust uses hardlinks in the build
by default. We have disabled this since it caused intermittent build failures
because env::current_exe (uses kern.proc.pathname.-1 sysctl internally) might
returns the wrong pathname (one of the hardlinks) sometimes and rustc fails
to find the right std crate.  This is my working theory anyway. It's difficult
to trigger the problem on my package builder.

I was going to experiment with switching it over to AT_EXECPATH but I guess
that will make no difference because of the current behavior of it.

If getexecname() would be just a wrapper for elf_aux_info(AT_EXECPATH) then
it wouldn't solve the problem either.

Any suggestions what we should use instead of kern.proc.pathname, AT_EXECPATH,
or /proc/curproc/file?

You are receiving this mail because:
You are the assignee for the bug.