rtld enhancement to add osversion, version 2

[John Baldwin]

On Wednesday, March 21, 2012 1:11:37 pm Doug Ambrisko wrote:
> | > This doesn't solve the LD_LIBRARY_PATH or LD_PRELOAD.  Solving that
> | > I still insert and iterate over the osverion, major and none into the
> | > path to find the library.  The reason for this is that a FreeBSD 8 
> | > binary could exec a FreeBSD 6 binary that execs a FreeBSD 7 binary.  
> | > If for the FreeBSD 6 binary we needed to set a custom LD_LIBRARY_PATH
> | > and the FreeBSD 7 binary find a library via the FreeBSD 6 search path
> | > then the FreeBSD 7 binary would die.  By adding in the osversion search
> | > path I can put the FreeBSD 6 library into the search path + the directory
> | > 6.  Then only FreeBSD 6 binaries can find it.  An example:
> | > 	LD_LIBRARY_PATH=/usr/custom_software/lib
> | > 	/usr/custom_software/lib/6/libfoo.so.6
> | > then only the FreeBSD 6 binary could load it.  Since the searches
> | > would be for the FreeBSD 6 binary:
> | > 	/usr/custom_software/lib/603000/libfoo.so.6
> | > 	/usr/custom_software/lib/6/libfoo.so.6
> | > 	/usr/custom_software/lib/libfoo.so.6
> | > and for FreeBSD 7 binary:
> | > 	/usr/custom_software/lib/702000/libfoo.so.6
> | > 	/usr/custom_software/lib/7/libfoo.so.6
> | > 	/usr/custom_software/lib/libfoo.so.6
> | > Only the FreeBSD 6 binary would load /usr/custom_software/lib/6/libfoo.so.6.
> | > I do the same search with LD_PRELOAD.
> | 
> | Hmm, I'm still not quite fan of this.  Perhaps you could add an extension to
> | ldconfig and the hints file to handle this case?  That is, a way to store
> | path mappings so you could do something like:
> | 
> | ldconfig -os=6 -p /usr/local/lib /usr/local/lib/6
> 
> I'll have to look to see how the hints file could update rtld.  It is
> an interesting idea.  Maybe libmap.conf would be better place for this.
> I haven't looked at how libmap works.  Maybe introduce:
> 	/etc/libmap-<OSVERSION>.conf
> that maps paths as well.  So with the above example.
> 	/etc/libmap-6.conf
> would contain
> 	/usr/custom_software/lib /usr/custom_software/lib/6:/usr/custom_software/lib
> for example.
>  
> | Or maybe you could make it an extension of how 'm' worked, so you could make
> | directories accept an optional set of colon-separated paths that they serve
> | as aliases for:
> | 
> | ldconfig -os=6 -m /usr/local/lib/6:/usr/local/lib:/usr/lib
> 
> I don't really get how this is solving the LD_LIBRARY_PATH/LD_PRELOAD since
> "-m" is solving the general case with the hints file which I did first.

It is just an alternate suggestion to the -p thing above.  Having a libmap.conf
option to establish the mappings would be fine with me as well.  I would just
like to have the library paths be something the user explicitly configures rather
than having rtld perform black-box path manipulations itself.

> | > Final, is that prior binaries built on FreeBSD i386 but run on FreeBSD amd64
> | > that set LD_* environemnt variables would fail on FreeBSD amd64 as is
> | > since it didn't set the equivalent LD32_*.  To address this for COMPAT_32BIT
> | > I have rtld look for LD32_* first and then check for the LD_* second.
> | > This way legacy applications work fine.
> | 
> | Hmm, so Yahoo! had some patches to handle this as well.  I think Yahoo's
> | patches were different though.  They actually patched the 32-bit libc to
> | capture attempts to get or set LD_* and convert them to actually get/set
> | LD32_* instead.  I'm not sure which approach is best, but it might be worth
> | asking Peter why Yahoo! did it that way and if there were reasons for that
> | approach vs. doing it in rtld.  I think the primary reason was so that you
> | could set LD_LIBRARY_PATH or LD_PRELOAD to reference 64-bit libraries and
> | not have it break 32-bit apps, but if a 32-bit app tried to set a variable
> | before launching another app it would still DTRT.
> 
> This means you would have to have a modified libc in these environment
> and it wouldn't help in the static binary case.  I think we are safe
> in the case LD_ for a 32 bit binary effecting a 64 bit since rtld should
> not allow loading a the wrong type of lib. into a binary.  I can do some
> more testing around that area.  I was trying to keep all changes in the
> host environment so we can run unchanged binaries from other vendors.

Yes, I'm not quite convinced which approach is best, mostly I just wanted to
point out the alternative approach so both could be considered.
  
-- 
John Baldwin