Re: AT_EXECPATH aux_info vector contains path of interpreter when directly exec'ing rtld
On Fri, Dec 20, 2019 at 04:26:41PM -0500, Ryan Stone wrote: > I've noticed that on head, if I directly execute rtld to run an > executable, AT_EXECPATH contains the path to rtld on head (on > 12.0-RELEASE it will contain nothing). This is causing me a problem > because clang uses AT_EXECPATH to preferentially locate where it's > installed, which it uses to locate its driver programs. > > The end result is that clang can no longer successfully be executed > from a process in capability mode, whereas before I could fexecve rtld > and give it a pre-opened file descriptor to /usr/bin/clang. > > I've put together a quick test program demonstrating the problem: > > https://people.freebsd.org/~rstone/getprogname.c > > On 12.0-RELEASE, directly executing rtld to run this program gives this > output: > $ /libexec/ld-elf.so.1 -- ./progname > progname: progname > argv[0]: ./progname > elf_aux_info failed: No such file or directory > > On head, I get this instead: > /libexec/ld-elf.so.1 -- ./progname > progname: progname > argv[0]: ./progname > AT_EXECPATH: /libexec/ld-elf.so.1 https://reviews.freebsd.org/D22894 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: AT_EXECPATH aux_info vector contains path of interpreter when directly exec'ing rtld
On Fri, 20 Dec 2019 at 16:26, Ryan Stone wrote: > > I've noticed that on head, if I directly execute rtld to run an > executable, AT_EXECPATH contains the path to rtld on head (on > 12.0-RELEASE it will contain nothing). This is causing me a problem > because clang uses AT_EXECPATH to preferentially locate where it's > installed, which it uses to locate its driver programs. I have two questions, I suppose: - What is the correct thing for AT_EXECPATH in light of fexecve rtld? Arguably /libexec/ld-elf.so.1 is correct. - What's the desired behaviour for Clang when run from ld-elf.so.1 -f fd? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: AT_EXECPATH aux_info vector contains path of interpreter when directly exec'ing rtld
Isn’t rtld’s behavior here correct? It’s really Clang which is doing something quite odd. On Fri, Dec 20, 2019 at 13:27 Ryan Stone wrote: > I've noticed that on head, if I directly execute rtld to run an > executable, AT_EXECPATH contains the path to rtld on head (on > 12.0-RELEASE it will contain nothing). This is causing me a problem > because clang uses AT_EXECPATH to preferentially locate where it's > installed, which it uses to locate its driver programs. > > The end result is that clang can no longer successfully be executed > from a process in capability mode, whereas before I could fexecve rtld > and give it a pre-opened file descriptor to /usr/bin/clang. > > I've put together a quick test program demonstrating the problem: > > https://people.freebsd.org/~rstone/getprogname.c > > On 12.0-RELEASE, directly executing rtld to run this program gives this > output: > $ /libexec/ld-elf.so.1 -- ./progname > progname: progname > argv[0]: ./progname > elf_aux_info failed: No such file or directory > > On head, I get this instead: > /libexec/ld-elf.so.1 -- ./progname > progname: progname > argv[0]: ./progname > AT_EXECPATH: /libexec/ld-elf.so.1 > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
AT_EXECPATH aux_info vector contains path of interpreter when directly exec'ing rtld
I've noticed that on head, if I directly execute rtld to run an executable, AT_EXECPATH contains the path to rtld on head (on 12.0-RELEASE it will contain nothing). This is causing me a problem because clang uses AT_EXECPATH to preferentially locate where it's installed, which it uses to locate its driver programs. The end result is that clang can no longer successfully be executed from a process in capability mode, whereas before I could fexecve rtld and give it a pre-opened file descriptor to /usr/bin/clang. I've put together a quick test program demonstrating the problem: https://people.freebsd.org/~rstone/getprogname.c On 12.0-RELEASE, directly executing rtld to run this program gives this output: $ /libexec/ld-elf.so.1 -- ./progname progname: progname argv[0]: ./progname elf_aux_info failed: No such file or directory On head, I get this instead: /libexec/ld-elf.so.1 -- ./progname progname: progname argv[0]: ./progname AT_EXECPATH: /libexec/ld-elf.so.1 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
