Re: Fixing $ORGIN RPATHs - at least some of them

[christos%zoulas.com@localhost (Christos Zoulas)]

On Nov 8,  9:39am, martin%duskware.de@localhost (Martin Husemann) wrote:
-- Subject: Re: Fixing $ORGIN RPATHs - at least some of them

| What we really want (for the topic of this thread) is: a reference to
| the directory the original binary was loaded from and a dlopenat() call
| for use by ld.elf_so if $ORIGIN is present in RPATH.

Just to be clear, the major benefit of doing things this way is
the savings due to the lazy getcwd in the $ORIGIN case. This getcwd
has the benefit of canonicalization which minimizes (but does not
eliminate) the race potential of a symlink hijack in the executable
path (which is not relevant anyway, because $ORIGIN should not be
honored in the set*id case).

Now to pass a reference to the directory of the executing program,
we need to either pass an fd to it from the kernel for every
executable (which requires more work from the kernel, plus we need to
figure out what to do with the extra fd in the new kernel+old binary
case), or provide a new system call (or hijack ioctl/sysctl to get it).

Either alternative seems more complicated than doing the
namei(LOCKPARENT) in the kernel and then doing the getcwd(dvp) right there
to find the path and then forming the normalized path and passing it
in AT_SUN_EXECNAME, unless I am missing the obvious.

| ld.elf_so does not care about the exe name (and most uses of rust's
| std::env::current_exe() that I could find immediately strip it back to
| the last / character, that is: care about the directory name only - or
| are mostly cosmetic and would better use argv[0]).

The things that need it are debuggers-like and other programs that
need to re-exec. As dh@ mentioned, this can be done by providing
a way to get a reference to the original binary (by fd?), but this
would require addition of fexecve() in the re-exec case (which has
issues of its own).  Not making the path available to executing
programs and providing those alternative methods to get access to
it, will cause NetBSD to be harder to port (and I am not taking
Don Quixote-like comments about showing people the right way to do
things seriously...)

| Also note that for cases like this all hard cases (like binaries doing
| chroot, directories being unreadable, directories being moved, ...)
| are irrelevant - failure to use $ORIGIN after one of those would count
| as operator error.

Indeed.

christos