[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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248184

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
13.0-RELEASE-p4
$ cat execpath.c
#include <sys/auxv.h>
#include <limits.h>
#include <stdio.h>

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

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.