[Bug 248184] readlink("/proc/curproc/file") returns arbitrary correct name for programs with more than one link (name)
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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.