NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: port-amd64/57265: Cross-build broken from Linux amd64 to NetBSD amd64



Hi!

On Thu, 2023-03-09 18:10:02 +0000, Jan-Benedict Glaw <jbglaw%lug-owl.de@localhost> wrote:
>  >  ++ export LD_LIBRARY_PATH=3D/usr/lib/gcc-snapshot/lib:
>  >  ++ LD_LIBRARY_PATH=3D/usr/lib/gcc-snapshot/lib:
>  > =20
>  >  Is that in your build environment?  What happens if you remove it?
>  
>  It is!  That's from a little to choose between different compilers
>  (ie. a recent GCC snapshot, the "usual" (older) system GCC, some CLANG
>  versions.  But that LD_LIBRARY_PATH should in no way enable ld.so to
>  pull in some libz (that's a guess) from the destdir, should it?
>  
>    Just started a build using the sytem compiler (not setting
>  anything). I wonder (read: hope!) that the empty path component
>  doesn't wrongly resolve to "." ...  (If the next build succeeds, my
>  next test would be LD_LIBRARY_PATH="/does_not_exist:"...)

Turns out: `bash` has the documented feature of treating an empty path
component in `$PATH` as the current directory---and GNU libc's `ld.so`
does the same for `$LD_LIBRARY_PATH`. So ... this ticket can be
closed, not having an trailing colon is the fix here, it's _not_ a
NetBSD issue at all. I'm sorry!  OTOH, I'll continue to inquire the
Debian Security team if this is desired behavior or a CVE-worthy bug.

  I guess that there are quite some place where people assign $PATH
and $LD_LIBRARY_PATH like this:

    export LD_LIBRARY_PATH="/my/lib:${LD_LIBRARY_PATH}"

which triggers this issue, at least for GNU ld.so .  The more correct
assignment would be

    export LD_LIBRARY_PATH="/my/lib{LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"

which is more clumpsy, but doesn't leave you deadly wounded...

  It seems NetBSD's ld.elf_so does do the same:

197 void
198 _rtld_add_paths(const char *execname, Search_Path **path_p, const char *pathstr)
199 {
 :
205         if (pathstr[0] == ':') {
206                 /*
207                  * Leading colon means append to current path
208                  */
209                 while ((*path_p) != NULL)
210                         path_p = &(*path_p)->sp_next;
211                 pathstr++;
212         }

The man page does not mention this somewhat surprising behavior as
well:

     LD_LIBRARY_PATH  A colon separated list of directories, overriding the
                      default search path for shared libraries.


Thanks,
  Jan-Benedict

-- 

Attachment: signature.asc
Description: PGP signature



Home | Main Index | Thread Index | Old Index